I stumbled across the following link right now:
In my opinion this kind of sealing up a device is an unacceptable measurement.
I suggest you check if there is such a security measurement documented and if it is boycott the respective producer.
ha! with backlight working! 😉
localhost ~ # uname -a
Linux localhost 3.1.10-00008-g03975b1-dirty #106 SMP PREEMPT Wed Apr 11 12:43:53 CEST 2012 armv7l ARMv7 Processor rev 0 (v7l) adam GNU/Linux
BenBE asked me to give him some advice how to open and manipulate network devices from user space.
Although it's not really a kernel hacking issue, as his way of asking proposed I'll post the respective link after all, because I've promised.
Usually you use APIs for such a purpose.
In this case its the library called Libdnet and the project page can be found under the following URL:
I just have taken a look into Debian's package viewer and somehow the relevant header ( /usr/include/dnet/tun.h )
is missing ( packages broken/outdated? O.o)
Anyway, the header file would only tell us that much (Thx to benny for the tip with the highlighter! 😉 ):
* Network tunnel device.
* Copyright (c) 2001 Dug Song
* $Id: tun.h,v 1.2 2005/01/25 21:29:12 dugsong Exp $
typedef struct tun tun_t;
tun_t *tun_open(struct addr *src, struct addr *dst, int mtu);
int tun_fileno(tun_t *tun);
const char *tun_name(tun_t *tun);
ssize_t tun_send(tun_t *tun, const void *buf, size_t size);
ssize_t tun_recv(tun_t *tun, void *buf, size_t size);
tun_t *tun_close(tun_t *tun);
#endif /* DNET_TUN_H */
An example can be found a little more deeper on the following site:
By using libudev for dynamic file checking and path allocation
you could also make it a little more dynamic and flexible.
(Using hardcoded strings in order to allocate files is usually a very bad idea)
bash_vi asked me to write a short resume about how to emerge programs by using the ramfs for speedup.
Here's how to do so:
mount -t ramfs -o size=2g ramfs /var/tmp/portage/
- The "-t ramfs" is obviously self explainatory.
- The "-o size" tells the ramfs driver how much space of the RAM should be reserved for this specific mount point.
- "/var/tmp/portage/" is the place where portage usually unpacks the source boundles and begins to compile them.
You can also put it into your
/etc/fstab in order to keep it for each reboot with
echo -e "ramfs\t/var/tmp/portage/\tramfs\tsize=2g\t0\t0" >> /etc/fstab
Now you can compile your stuff within RAMFS
At least someone got Plasma-Active running on the NI Adam:
But 2.6.38 , where 3.2 would be recent is really a NO-GO.
Why don't you write code which can be merged into upstream again?
I'm really pissed.
It's again the same shit as with my HTC dream (or should I say nightmare?)
Ages outdated kernel, branches with drivers which are that badly written that they can never be merged into Torvalds master again.
Dudes! Can't you have a look over to Texas Instruments?!
The OMAP is well documented, there are free drivers available and there is always support in main.
WTF? What use is a kernel where no peripherial drivers are available within the official, recent kernel?!
Long time has it been, now a tech-update
KDE4 and Gentoo
It's the small things in life which are important, like for example, finally figuring out, that just replacing "%d : %n" with "%d : %w" in my Konsole-profile finally also makes Konsole show me the recent package, emerge is compiling in the title-bar (like xterm always does)
Tomorrow my 16GB µSD card should arrive, on which I'll install Kubuntu-Mobile, in order to test Plasma-Active on my GTA04
I'm really working this time on the stuff.
It's ETHZ matter of a year strechted onto two, so this time, it's doable... Hopefully...
It's looks well so far, anyway... 😉