Updated mdev

Frank Sorenson frank at tuxrocks.com
Tue Dec 13 08:27:48 UTC 2005

Hash: SHA1


If you haven't already completed a rewrite, here's my improved version.
 I believe I address all the issues you've mentioned.  I've also cleaned
it up, fixed small bugs, tested more thoroughly, etc.  This code
probably still needs some significant cleaning-up, but...!

Rob Landley wrote:
> On Monday 12 December 2005 10:18, Frank Sorenson wrote:
> Well, gcc can definitely lead to that sort of thinking.  Linking against 
> uClibc and klibc, however, tends to give much more sane results.

Very good to know.  I'll just implement it all using the regular
functions, and let the libraries fix it up for size.

>>>Looking at get_device_info (which is another function that's called from
>>>only one place): BUFFER_LENGTH was chosen how?  (I'd be more comfortable
>>>with bb_asprintf() here.)  The check if (ret ==0 ) leaks the filehandle,
>>>and doesn't catch the actual error return value (-1) which would leading
>>>to the buf[ret-1]=0 assignment writing outside the buffer...

Fixed up!

>>>All this stuff with netlink needs a CONFIG_ and #ifdefs.

Done (not sure if it's right, but it's done! :)

CONFIG_HOTPLUG now selects whether or not to do the whole kernel-netlink
bit that detects hotplug.  Configged out, it appears to save about 1500

  Is there
>>>_really_ no better header to include than linux/netlink.h and
>>Not sure.  The udev code itself went this way, and I wasn't aware of
> I haven't looked at any remotely recent udev code, but I'll take a look and 
> see what else I can come up with.

Okay, looks like we can do away with those headers just by defining
sockaddr_nl ourselves.  Small price to pay.

>>>process_netlink_message:   Apparently, it can never get a block device
>>>hotplugged over netlink, just char devices.

This should be more clear now.

>>>So when this program is run with no arguments, it does nothing?  (Not
>>>even a help message?)

Complains now, but we could always set a default action.

>>>Did you see any of the discussion on the busybox list about a minimal
>>>config file format to specify ownership and permissions for devices?
>>Yes.  It shouldn't be too difficult to add the code to read the config
>>and set permissions and ownership.
> Cool.
> I can code this up if you like.  I _think_ all we need is the device 
> permissions and ownership syntax (with regex support), and the shellout 
> syntax.  All the stuff about creating symlinks and directories we really 
> don't need to do.  If we don't mount /dev or /sys then the script that does 
> that (and then calls us) can do any other setup required.

I left in a TODO comment where we'd address this.  _Real_ udev appears
to use inotify to check for updates to the config files, but that seems
like overkill.  We could either load at startup, or re-read each time a
device is added.

- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank at tuxrocks.com
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mdev.c
Type: text/x-csrc
Size: 5171 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20051213/ee72b1b8/attachment.c 

More information about the busybox mailing list