[Buildroot] mdev handling

[Buildroot] mdev handling

[Yegor Yefremov]

AFAIK mdev activation leads only to adding this binary to the rootfs
tree. What about starting script? Would it make sense to create
/etc/init.d/S1mdev with the following content:

#!/bin/sh
#
# Start the mdev....
#

case "$1" in
  start)
        echo "Starting mdev..."
        echo /sbin/mdev > /proc/sys/kernel/hotplug
        /sbin/mdev -s
        ;;
  stop)
.......

echo /sbin/mdev > /proc/sys/kernel/hotplug - only if such an option
selected. fstab should be also changed to have

tmpfs           /dev           tmpfs    size=1M          0      0

added. (The size should be much smaller, this is only for testing)

What do you think about this?

Regards,
Yegor

[Buildroot] mdev handling

[William Wagner]

  On 08/09/2010 15:07, Yegor Yefremov wrote:
> AFAIK mdev activation leads only to adding this binary to the rootfs
> tree. What about starting script? Would it make sense to create
> /etc/init.d/S1mdev with the following content:
>
> #!/bin/sh
> #
> # Start the mdev....
> #
>
> case "$1" in
>    start)
>          echo "Starting mdev..."
>          echo /sbin/mdev>  /proc/sys/kernel/hotplug
>          /sbin/mdev -s
>          ;;
>    stop)
> .......

This is what I do on every project I use with mdev, seems like adding an 
option would be good

> echo /sbin/mdev>  /proc/sys/kernel/hotplug - only if such an option
> selected. fstab should be also changed to have
>
> tmpfs           /dev           tmpfs    size=1M          0      0
>
> added. (The size should be much smaller, this is only for testing)

Again these two sound like sensible options.

Regards
Will

> What do you think about this?
>
> Regards,
> Yegor
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] mdev handling

[Peter Korsgaard]

>>>>> "Yegor" == Yegor Yefremov <yegorslists@googlemail.com> writes:

 Yegor> AFAIK mdev activation leads only to adding this binary to the rootfs
 Yegor> tree. What about starting script? Would it make sense to create
 Yegor> /etc/init.d/S1mdev with the following content:

 Yegor> tmpfs           /dev           tmpfs    size=1M          0      0

 Yegor> added. (The size should be much smaller, this is only for testing)

 Yegor> What do you think about this?

Isn't this largely obsolete now we have devtmpfs?

-- 
Bye, Peter Korsgaard

[Buildroot] mdev handling

[Yann E. MORIN]

Peter, Yegor, All,

On Wednesday 08 September 2010 16:29:15 Peter Korsgaard wrote:
> >>>>> "Yegor" == Yegor Yefremov <yegorslists@googlemail.com> writes:
> 
>  Yegor> AFAIK mdev activation leads only to adding this binary to the rootfs
>  Yegor> tree.
[--SNIP-]
> Isn't this largely obsolete now we have devtmpfs?

Well, devtmpfs has a static naming scheme, default permissions for device
nodes, so it is not sufficient by itself. As the help entry for devtmpfs
states:
 "It provides a fully functional /dev directory, where usually
  udev runs on top, managing permissions and adding meaningful
  symlinks."

So, even from the kernel devels, udev/mdev can/should/must be used to get
a properly managed /dev, even with devtmpfs.

And I don't trust/want the kernel to provide/handle policy. It belongs to
userspace.

Even better, embedded system have a mostly static set of devices, thus a
mostly static set of entries in /dev, and those can go to flash. Entries
for removeable devices (eg. usb sticks) can still go there. Thus you gain
both in flash (no space used by any code, kerenl or userland) and in RAM
(no space used by devtmpfs/tmpfs/ramfs/... and VFS entries).

Really, devtmpfs and mdev/udev are for desktop, where the set of devices is
to easily divergent, IMHO...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] mdev handling

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@anciens.enib.fr> writes:

Hi,

 >> Isn't this largely obsolete now we have devtmpfs?

 Yann> Well, devtmpfs has a static naming scheme, default permissions for device
 Yann> nodes, so it is not sufficient by itself. As the help entry for devtmpfs
 Yann> states:
 Yann>  "It provides a fully functional /dev directory, where usually
 Yann>   udev runs on top, managing permissions and adding meaningful
 Yann>   symlinks."

True, but it is fine for most small embedded systems as well (E.G. the
target group of buildroot). Most of these are root only so you just want
the device nodes of the hw you have available.

But yes, it can certainly be used with mdev as well (you basically just
get rid of the slow mdev -s at startup).

 Yann> Even better, embedded system have a mostly static set of devices, thus a
 Yann> mostly static set of entries in /dev, and those can go to flash. Entries
 Yann> for removeable devices (eg. usb sticks) can still go there. Thus you gain
 Yann> both in flash (no space used by any code, kerenl or userland) and in RAM
 Yann> (no space used by devtmpfs/tmpfs/ramfs/... and VFS entries).

The devtmpfs code is very small if you already have ramfs/tmpfs (and
most likely you do), so the size difference between devtmpfs and static
/dev is really down in the noise.

 Yann> Really, devtmpfs and mdev/udev are for desktop, where the set of
 Yann> devices is to easily divergent, IMHO...

Depends on what you want to do. You fairly often see embedded devicess
that react when you plug in a usb device. For that, mdev (or other
hotplug scripts) are pretty nice.

-- 
Bye, Peter Korsgaard

[Buildroot] mdev handling

[Yegor Yefremov]

> ?Yegor> AFAIK mdev activation leads only to adding this binary to the rootfs
> ?Yegor> tree. What about starting script? Would it make sense to create
> ?Yegor> /etc/init.d/S1mdev with the following content:
>
> ?Yegor> tmpfs ? ? ? ? ? /dev ? ? ? ? ? tmpfs ? ?size=1M ? ? ? ? ?0 ? ? ?0
>
> ?Yegor> added. (The size should be much smaller, this is only for testing)
>
> ?Yegor> What do you think about this?
>
> Isn't this largely obsolete now we have devtmpfs?

Yes, it is working like a charm. You live and learn.

But the creation of an init.d script is still worth implementing?

I'd suggest to make an option "Target filesystem options"->"Device
creation" and then
 "Target filesystem options"->"Device creation"->"static" and as
suboption "device table file"
 "Target filesystem options"->"Device creation"->"dynmic" and as
suboptions "udev" and "mdev"
 and then something with hotplugging

Regards,
Yegor

[Buildroot] mdev handling

[Thomas Petazzoni]

On Thu, 9 Sep 2010 11:01:52 +0200
Yegor Yefremov <yegorslists@googlemail.com> wrote:

> But the creation of an init.d script is still worth implementing?
> 
> I'd suggest to make an option "Target filesystem options"->"Device
> creation" and then
>  "Target filesystem options"->"Device creation"->"static" and as
> suboption "device table file"
>  "Target filesystem options"->"Device creation"->"dynmic" and as
> suboptions "udev" and "mdev"
>  and then something with hotplugging

Here is what I have on my personal TODO list:

 "Add an option to select the creation mode of device files :

   * Static with a device table
   * Using devtmfs
   * Using mdev
   * Using udev
 "

Of course, if someone wants to remove an item from my TODO list, that'd
be very nice !

Cheers,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] mdev handling

[Yegor Yefremov]

On Thu, Sep 9, 2010 at 12:19 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Thu, 9 Sep 2010 11:01:52 +0200
> Yegor Yefremov <yegorslists@googlemail.com> wrote:
>
>> But the creation of an init.d script is still worth implementing?
>>
>> I'd suggest to make an option "Target filesystem options"->"Device
>> creation" and then
>> ?"Target filesystem options"->"Device creation"->"static" and as
>> suboption "device table file"
>> ?"Target filesystem options"->"Device creation"->"dynmic" and as
>> suboptions "udev" and "mdev"
>> ?and then something with hotplugging
>
> Here is what I have on my personal TODO list:
>
> ?"Add an option to select the creation mode of device files :
>
> ? * Static with a device table
> ? * Using devtmfs
> ? * Using mdev
> ? * Using udev
> ?"

What should "Using devtmfs" make? Enable/disable this option in kernel?

> Of course, if someone wants to remove an item from my TODO list, that'd
> be very nice !

Let's try this.

Yegor

[Buildroot] mdev handling

[Thomas Petazzoni]

On Thu, 9 Sep 2010 12:38:13 +0200
Yegor Yefremov <yegorslists@googlemail.com> wrote:

> What should "Using devtmfs" make? Enable/disable this option in
> kernel?

Yes, probably, and make sure that devtmpfs is mounted as needed
(/etc/fstab).

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] mdev handling

[Yegor Yefremov]

>> What should "Using devtmfs" make? Enable/disable this option in
>> kernel?
>
> Yes, probably, and make sure that devtmpfs is mounted as needed
> (/etc/fstab).

Does it have to be mounted? It is made by the kernel just after
mounting the rootfs (at least there is such a kernel option):

CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

So our initial /etc/fstab is sufficient for this purpose.

Yegor

[Buildroot] mdev handling

[Yegor Yefremov]

>> But the creation of an init.d script is still worth implementing?
>>
>> I'd suggest to make an option "Target filesystem options"->"Device
>> creation" and then
>> ?"Target filesystem options"->"Device creation"->"static" and as
>> suboption "device table file"
>> ?"Target filesystem options"->"Device creation"->"dynmic" and as
>> suboptions "udev" and "mdev"
>> ?and then something with hotplugging
>
> Here is what I have on my personal TODO list:
>
> ?"Add an option to select the creation mode of device files :
>
> ? * Static with a device table
> ? * Using devtmfs
> ? * Using mdev
> ? * Using udev
> ?"

udev has dependency BUSYBOX_SHOW_OTHERS. Is it because of mdev?

Yegor

[Buildroot] mdev handling

[Peter Korsgaard]

>>>>> "Yegor" == Yegor Yefremov <yegorslists@googlemail.com> writes:

Hi,

 Yegor> udev has dependency BUSYBOX_SHOW_OTHERS. Is it because of mdev?

Yes, mdev is a "replacement" of udev. This is done for a number of
packages. You can argue about udev/mdev, as mdev doesn't have the same
user interface as udev, but that's how it is today atleast.
-- 
Bye, Peter Korsgaard