[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

replacing makedev

I've started work on this, but I figured I'd shoot an email to the list
for suggestions/comments.  The current makedev script (/sbin/MAKEDEV) is
rather lacking in a few respects:

1) It does a nasty 'eval "major_$device=$major"', where $device and
$major come from /proc/devices, for every single device listed.  This
breaks with devices that have names that aren't allowed as shell
variable names, such as "device-mapper".  This is also apparent in bug
#104254.  It wouldn't be as annoying if it only happened when trying to
create said devices, but breakage occurs when trying to use makedev at

2) One must file a wishlist bug and wait for the makedev maintainer to
add the entry when they need new devices added.  This seems rather

The fact that it's written in shell makes it a rather ugly looking
beast, as well.  Since it's located in /sbin, it can't depend upon
anything in /usr, so using other languages aren't possible; this leaves
shell and C.

Looking at redhat's makedev, they have device nodes in /etc/makedev.d,
so that packages can simply add files to that directory to create new
devices.  This is the way debian seems to do things in other cases, and
would be a good thing to do, imo.  So, I've started rewriting it in C,
to have it use /etc/makedev.d.

A few of the other wishlist bugs could be handled as well; #99151, for

I'd like some feedback on whether people think this is a good idea or
not.  Also, I've noticed the debian-netbsd folks have their own makedev
package; this is the sort of thing that could be handled a lot cleaner
in a redesigned makedev package.  For example, having
/etc/makedev.$OS, or having /etc/makedev.d/foo.$OS (the latter having
the added bonus of not having to special case things like
/etc/makedev.d/foo.dpkg-*, as the node files would be treated as proper
conf files).  So, feedback from other debian ports who need to hack
around the current makedev script would be nice.

Broad surveillance is a mark of bad security.
	-- Bruce Schneier

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: