On Tuesday 03 June 2008, Bernard Blackham wrote: > Mike Frysinger wrote: > > you'll also need to make sure you do this somewhere which has temporary > > storage ... otherwise you'll wreck embedded flash systems > > /dev is on tmpfs anyway.
not always ... but for the cases which i'm flagging, they'd better be or you're already wrecking things :) > > *shrug* anything not daemon/netlink based looks like a hack to me > > And I'm inclined to agree. > > > which means i still dont understand why people dont go use udevd if > > they need a real setup. > > s/real/reliable/ > > What good is using mdev if it cannot be relied upon? (apart from using > mdev -s at boot and an otherwise completely-static /dev). this is actually a significant base for which mdev is perfect > [... snip ...] > > > better, just use udevd (which i honestly dont think is a big deal, it > > isnt exactly bloated ... it's 76k on x86_64 and it's built for speed, > > not size). > > It's 66K stripped on arm and built for size (the Makefile for udev-120 > does this by default). 66K is a lot for a critical daemon. i'd disagree. ignoring busybox, 66k is pretty damn tight considering everything udev offers. > It does a > *lot* of stuff that nobody needs - it maintains a database in /dev/.udev > of all devices and exports lots of information to userspace which > probably does not matter to most embedded systems. it does a *lot* of stuff that people keep asking to add to mdev. historically i declined anything but the bare min stuff as imo, we're wasting time reinventing a perfectly good wheel. Denys seems to be more open to merging features. > I'd like someone to answer my original proposal of whether or not a > simple daemon running in a loop would suffice. I imagine the resulting > binary would be a mere few kilobytes in size, as *all* it needs to do is > serialize requests and pass them to mdev. Nothing more. writing a standalone binary does not fit the busybox design. i doubt mdevd would be terribly difficult to do with real netlink sockets/daemon. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
