Re: mirroring /dev somewhere else
On 12.11.2010 19:13, Mulyadi Santosa wrote: On Fri, Nov 12, 2010 at 20:14, Christophe Aeschlimann c.aeschlim...@acn-group.ch wrote: On 12.11.2010 13:34, Christophe Aeschlimann wrote: The problem I have is with recreating the /dev inside my mini rootfs. I'm using udev and I don't know how to instruct udev to mirror the content of /dev in /var/tmp/update/dev/. Or maybe I can just create the devices (mtdX) I need using mknod ? Would that work (I'll be trying) ? Maybe I'll answer myself here but would just copying the devices from /dev/ to /var/tmp/update/dev/ work ? does mount --bind help? please kindly check man mount too Thanks for the trick ! What I did is cp -a /dev/* /var/tmp/udpdate/dev/ which works fine. But I'll keep your solution in a corner of my head :) -- Christophe Aeschlimann Embedded Software Engineer Advanced Communications Networks S.A. Rue du Puits-Godet 8a 2000 Neuchâtel, Switzerland Tél. +41 32 724 74 31 c.aeschlim...@acn-group.ch -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: mirroring /dev somewhere else
On 15.11.2010 09:42, Mulyadi Santosa wrote: On Mon, Nov 15, 2010 at 15:18, Christophe Aeschlimann c.aeschlim...@acn-group.ch wrote: does mount --bind help? please kindly check man mount too Thanks for the trick ! What I did is cp -a /dev/* /var/tmp/udpdate/dev/ which works fine. But I'll keep your solution in a corner of my head :) well, nice...but uhm, pardon me, cp? Are you sure? cp is copying content, you know...while mount --bind it's like doing symbolic link..and IMHO bind mount should be the choice. But maybe I missed something... Sure ! I'll make sure I read about mount --bind and change my solution to you cleaner one when I have some time. All in all, congrats ! :) Thanks for your help. -- Christophe Aeschlimann Embedded Software Engineer Advanced Communications Networks S.A. Rue du Puits-Godet 8a 2000 Neuchâtel, Switzerland Tél. +41 32 724 74 31 c.aeschlim...@acn-group.ch -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
mirroring /dev somewhere else
Hi, I'm working on a custom arm embedded system and I would like to implement a live system update. The system is running from NAND flash and has two mtd partitions one to store the kernel and another one to store the filesystem (jffs2/mtd). To be able to gracefully update the file-system from a running state I would like to: - kill all the running processes - remount file system as read only - create a small rootfs in /var/tmp/update/ (in ram) with the required tools (mainly erase/write flash and reboot) - copy the updated filesystem (fs.jffs2) to /var/tmp/update/ - chroot in my small rootfs and execute o flash_eraseall /dev/mtdX o nandwrite -p /dev/mtdX fs.jffs2 o reboot The problem I have is with recreating the /dev inside my mini rootfs. I'm using udev and I don't know how to instruct udev to mirror the content of /dev in /var/tmp/update/dev/. Or maybe I can just create the devices (mtdX) I need using mknod ? Would that work (I'll be trying) ? Best regards, -- Christophe Aeschlimann Embedded Software Engineer Advanced Communications Networks S.A. Rue du Puits-Godet 8a 2000 Neuchâtel, Switzerland Tél. +41 32 724 74 31 c.aeschlim...@acn-group.ch -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: mirroring /dev somewhere else
On 12.11.2010 13:34, Christophe Aeschlimann wrote: Hi, I'm working on a custom arm embedded system and I would like to implement a live system update. The system is running from NAND flash and has two mtd partitions one to store the kernel and another one to store the filesystem (jffs2/mtd). To be able to gracefully update the file-system from a running state I would like to: - kill all the running processes - remount file system as read only - create a small rootfs in /var/tmp/update/ (in ram) with the required tools (mainly erase/write flash and reboot) - copy the updated filesystem (fs.jffs2) to /var/tmp/update/ - chroot in my small rootfs and execute o flash_eraseall /dev/mtdX o nandwrite -p /dev/mtdX fs.jffs2 o reboot The problem I have is with recreating the /dev inside my mini rootfs. I'm using udev and I don't know how to instruct udev to mirror the content of /dev in /var/tmp/update/dev/. Or maybe I can just create the devices (mtdX) I need using mknod ? Would that work (I'll be trying) ? Maybe I'll answer myself here but would just copying the devices from /dev/ to /var/tmp/update/dev/ work ? (I'll keep you informed if that worked) Thanks ! Best regards, -- Christophe Aeschlimann Embedded Software Engineer Advanced Communications Networks S.A. Rue du Puits-Godet 8a 2000 Neuchâtel, Switzerland Tél. +41 32 724 74 31 c.aeschlim...@acn-group.ch -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Concurrent accesses to sysfs
On 06.09.2010 15:59, Greg KH wrote:
On Mon, Sep 06, 2010 at 09:23:06AM +0200, Christophe Aeschlimann wrote:
On 04.09.2010 02:58, Greg KH wrote:
On Tue, Aug 24, 2010 at 11:52:07AM +0200, Christophe Aeschlimann wrote:
Hi,
I'm implementing a user-space API that will give access to
custom hardware features through sysfs. This library is here
to hide the sysfs specifics.
Ick, don't.
What's wrong with the existing sysfs interfaces we have today, open(),
read(), close()?
And what type of hardware features are you wanting to export through
sysfs? Why sysfs?
Well we have to offer a board-support-package to a customer. When I told
them about sysfs to access LEDS / GPIOS they told me they wanted some layer
above that so they can just call a switch_led_on function and they
wouldn't have to know the way sysfs works. E.G. Know the sysfs path name,
attributes names and values to write to the attributes to control the device.
{sigh} Ok, then write a tiny shell script that does this :)
I would like to know if something special must be done in
this library to assure concurrent accesses.
Here is an example :
I want the users of my library to be able to switch-on/-off a LED using
a simple function like the following :
platform_led_on(0); //switches on led '0'
platform_led_off(0); //switches on led '0'
This led is declared in my platform_data in the board init file as a
gpio_led and can be seen in sysfs under /sys/class/leds/led0
the platform_led_on/off(0) functions will :
- build the sysfs path to the led0 based on the argument (0)
- open the brightness file in the sysfs path
- write to the brightness file a value != 0 to switch the led on or 0 to
switch it off
- close the brightness file
- return
Now what will happen if a thread tries to switch on the led while another
thread tries to switch it off ?
Who ever writes to the file first will cause their action to happen,
followed by the action of the second process/thread.
What happens with the open() on sysfs pseudo files ?
The file descriptor is returned, what exactly are you worried about
here?
Can the file be opened twice ?
Yes, multiple times, try it.
Or does it requires a close first ?
Nope.
If you need locking, do it in your library, but again, this really looks
like overkill, why do you need to do all of this?
Because it's a customer request :)
What type of locking are they asking for?
Is it possible to do the locking with the open() or flock() ? Or should I use
pthread mutex ?
open() isn't going to work.
flock() might, haven't tried it though.
a mutex would, if you are controling all access through your library.
But that's really overkill here, right?
Oh, and you have looked at libudev, right?
No I wasn't aware of that lib but I guess :
udev_device_get_sysattr_value ()
does the open/read/close for me in a thread-safe way ?
Again, what does thread-safe mean here?
The above call opens the file and reads the value and then closes the
file and returns the value to your program. If someone else went in and
wrote to the file right after reading to it, your read will be stale.
That makes it clear for me. Since I wasn't sure of the behaviour of open/close
(exclusive / non-exclusive) and read/write (atomic/non-atomic) I was getting
worried that it might not behave correctly.
Which is the same thing that would happen with your mutex lock as well,
right? You aren't going to ever be able to conclusivly say, Here is
the value, no one else has changed it.
Sure.
So again, I think you are over thinking this a lot. Just wrap up the
libudev call if you want, or just point your customer at libudev if they
are writing their own programs.
I think you got the point, I'm always over thinking :)
I will wrap the libudev call and everything is going to be fine.
Thanks for the help !
Regards,
Christophe
Or just write a simple shell script :)
good luck,
greg k-h
--
Christophe Aeschlimann
Embedded Software Engineer
Advanced Communications Networks S.A.
Rue du Puits-Godet 8a
2000 Neuchâtel, Switzerland
Tél. +41 32 724 74 31
c.aeschlim...@acn-group.ch
--
To unsubscribe from this list: send an email with
unsubscribe kernelnewbies to ecar...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Concurrent accesses to sysfs
Hi Greg, Thanks for taking the time to answer my email. On 04.09.2010 02:58, Greg KH wrote: On Tue, Aug 24, 2010 at 11:52:07AM +0200, Christophe Aeschlimann wrote: Hi, I'm implementing a user-space API that will give access to custom hardware features through sysfs. This library is here to hide the sysfs specifics. Ick, don't. What's wrong with the existing sysfs interfaces we have today, open(), read(), close()? And what type of hardware features are you wanting to export through sysfs? Why sysfs? Well we have to offer a board-support-package to a customer. When I told them about sysfs to access LEDS / GPIOS they told me they wanted some layer above that so they can just call a switch_led_on function and they wouldn't have to know the way sysfs works. E.G. Know the sysfs path name, attributes names and values to write to the attributes to control the device. This library must support multi-threaded accesses. sysfs handles that just fine. Thanks for confirming that. I would like to know if something special must be done in this library to assure concurrent accesses. Here is an example : I want the users of my library to be able to switch-on/-off a LED using a simple function like the following : platform_led_on(0); //switches on led '0' platform_led_off(0); //switches on led '0' This led is declared in my platform_data in the board init file as a gpio_led and can be seen in sysfs under /sys/class/leds/led0 the platform_led_on/off(0) functions will : - build the sysfs path to the led0 based on the argument (0) - open the brightness file in the sysfs path - write to the brightness file a value != 0 to switch the led on or 0 to switch it off - close the brightness file - return Now what will happen if a thread tries to switch on the led while another thread tries to switch it off ? Who ever writes to the file first will cause their action to happen, followed by the action of the second process/thread. What happens with the open() on sysfs pseudo files ? Can the file be opened twice ? Or does it requires a close first ? If you need locking, do it in your library, but again, this really looks like overkill, why do you need to do all of this? Because it's a customer request :) Is it possible to do the locking with the open() or flock() ? Or should I use pthread mutex ? Oh, and you have looked at libudev, right? No I wasn't aware of that lib but I guess : udev_device_get_sysattr_value () does the open/read/close for me in a thread-safe way ? thanks, greg k-h Thank you, Christophe -- Christophe Aeschlimann Embedded Software Engineer Advanced Communications Networks S.A. Rue du Puits-Godet 8a 2000 Neuchâtel, Switzerland Tél. +41 32 724 74 31 c.aeschlim...@acn-group.ch -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Concurrent accesses to sysfs
Hi, I'm implementing a user-space API that will give access to custom hardware features through sysfs. This library is here to hide the sysfs specifics. This library must support multi-threaded accesses. I would like to know if something special must be done in this library to assure concurrent accesses. Here is an example : I want the users of my library to be able to switch-on/-off a LED using a simple function like the following : platform_led_on(0); //switches on led '0' platform_led_off(0); //switches on led '0' This led is declared in my platform_data in the board init file as a gpio_led and can be seen in sysfs under /sys/class/leds/led0 the platform_led_on/off(0) functions will : - build the sysfs path to the led0 based on the argument (0) - open the brightness file in the sysfs path - write to the brightness file a value != 0 to switch the led on or 0 to switch it off - close the brightness file - return Now what will happen if a thread tries to switch on the led while another thread tries to switch it off ? Thank your for your comments / help. Best regards, -- Christophe Aeschlimann Embedded Software Engineer Advanced Communications Networks S.A. Rue du Puits-Godet 8a 2000 Neuchâtel, Switzerland Tél. +41 32 724 74 31 c.aeschlim...@acn-group.ch -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Question about kernel module syntax !!
Woodrow Douglass a écrit :
Bob Beers wrote:
On Mon, May 11, 2009 at 5:22 PM, Robert P. J. Day
rpj...@crashcourse.ca wrote:
On Mon, 11 May 2009, Bob Beers wrote:
On Mon, May 11, 2009 at 5:00 PM, RT Mistler rtmist...@techen.com
wrote:
Hi,
I've been looking at some kernel modules trying to map an embedded
devices resources and while going through a driver, I encountered an
if test that employed !!, example:
if !!function_foo(args) {
...
}
What does the !! do? (I'm familiar with a single !)
IIANM, it does ! and then does ! again, forcing boolean value,
true or false.
it's not clear why that would make any difference since 0 is boolean
false and everything else is boolean true. so under what
circumstances would doing a double negation change execution
behaviour? or am i missing something?
Well, the OP's example is not a real example from the kernel source.
A usage I can imagine is where one requires a *boolean* value,
not just 0 or not 0. This usage, !!, provides that
conversion, no?
-Bob
In my experience, saying if (!!x) produces cleaner assembly on some
architectures than if (x). Your mileage may vary.
Yes I think it is similar to what the likely macro defines :
http://lxr.linux.no/linux+v2.6.29/include/linux/compiler.h#L105
Christophe
-Woody
--
To unsubscribe from this list: send an email with
unsubscribe kernelnewbies to ecar...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ
--
To unsubscribe from this list: send an email with
unsubscribe kernelnewbies to ecar...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ
