MAKEDEV-1.7 and hdx >hdg
msbREMOVE-THIS at winterdrache.de
Mon Jan 26 04:50:34 PST 2004
On Mon, 26 Jan 2004 14:01:11 +1100 Greg Schafer <gschafer at zip.com.au>
> On Sun, Jan 25, 2004 at 07:13:26PM +0100, Matthias Benkmann wrote:
> > I've attached an updated version (only minor changes)
> Wow, there looks to be a fair amount of work in that!
Yes. A LOT of work :-)
> I'm assuming
> you've somehow auto-extracted most of it from devices.txt. Otherwise,
> the chances for errors to creep in would be rather huge.
Yes. And more importantly it would have taken me months to write the file
> Only a minor point, but it looks to be based on devices.txt from 2.4
> kernel sources.
Is that surprising? Look into Bugzilla. I suggested this as a replacement
for MAKEDEV back in 2001. That's why I was joking about Archaic never
giving up. I have lost all hope for this to ever go into the book.
> It may be prudent to base it on 2.6 to future-proof it.
New devices will have to be added by hand. devices.txt is not really
machine-parsable and it doesn't have all the group information etc. My
make_devices is the result of a lot of sedding on devices.txt (different
device groups needed different seds) and on ls -la /dev output from a SuSE
system. Then there was a tremendous amount of hand-editing to rearrange
the devices in a reasonable fashion and to add more explicit mknod lines
where devices.txt had only "..." . This is an effort that I will not
repeat. And I don't think I need to. Device numbers don't change much.
IIRC Linus installed a "No new device nodes unless absolutely necessary!"
policy a long time ago. If an LFS user ever discovers a device that he
needs and that isn't in make_devices, he'll report it and it'll be added.
Surely you won't hold being based on devices.txt from 2.4 against
make_devices. MAKEDEV is not directly based on ANY devices.txt. It's even
more outdated and has had lots of bugs with respect to device numbers and
apparently still has some (see the reason for this thread). make_devices
has always been and will always be better than MAKEDEV.
> On Sat, Jan 24, 2004 at 09:11:34PM -0500, Archaic wrote:
> > There is still the script Matthias Benkmann wrote. It's in Bugzilla.
> > It provides us with the best of both worlds. A scriptable dev creator
> > with the learning value of giving the mknod commands.
> Hmmm, not sure I'd buy the "best of both worlds" line after taking a
> look at the script. It certainly does the business, but "giving the
> mknod commands"? What's wrong with "man mknod" ?
The mknod manpage is way too technical for the average user and it doesn't
answer the only question that is important for users:"How do I create
/dev/xxx" (where xxx is a device that the user needs to create according
to some program/documentation). If the user is not discouraged by the
technobabble, studies the manpage really hard and follows the pointer to
devices.txt, he may be able to create the device he needs in the end, but
regarding groups and permissions he's on his own and will end up on
> I've always felt that
> asking the user to manually mknod the devices was taking the "from
> scratch" spirit way too far.
You're absolutely right. That's why I created make_devices. You don't have
to issue any mknod commands. You simply remove the # in front of the line
of the device you need and rerun make_devices.
make_devices is a compromise. The original idea of Bug 131 is certainly
too extreme, but MAKEDEV on the other hand is too much of a black box.
And of course there are more advantages than the educational aspect:
a) Creates only the devices you need
b) Records your choice of devices, so when building your next LFS you can
simply reuse your old customized make_devices
c) probably more sensible groups/permissions as they are based on a
comparison of a SuSE system and what MAKEDEV creates
d) Group and permission assignments much easier to change and more
flexible than with MAKEDEV
e) fewer bugs than MAKEDEV
f) easier to maintain and update than MAKEDEV
g) easier to understand than MAKEDEV, i.e. gives the LFS-user more of this
warm fuzzy "I understand what is happening" feeling.
h) it's an LFS-original rather than a modified script taken from some
> The FHS does say that "/dev must contain a command named MAKEDEV,
Like politicians the FHS says a lot of things :-)
> can create devices as needed" so it would certainly qualify as that if
> it were installed as /dev/MAKEDEV. However, it obviously wasn't designed
> to be user friendly. IMHO, our MAKEDEV should function in a similar way
> to how most other MAKEDEV's work.
Most other MAKEDEVs are opaque black boxes, perfectly suitable for the
usual opaque black box distros. I don't see a reason to imitate this for
> My vote would be to stick with current MAKEDEV until 2.6 kernel goes
> into the book and by then hopefully udev will be some sort of functional
This is all speculation. We don't know when udev will be ready and there
are certainly situations where a mostly user-space script-driven solution
like udev is undesirable. And don't forget that not everyone
will/can/wants to update to kernel 2.6 for a long time to come. And even
more time will pass till we can assume that the HOST for building LFS has
a 2.6 kernel (We need some devices in chroot if I'm not mistaken). It has
always been LFS-policy not to impose requirements on the host system
unless absolutely necessary. That was the argument against using things
like mount --bind in the past and it will be the argument against
requiring a 2.6 kernel on the host in future. Even if LFS switches to udev
in the regular instructions, it WILL create device nodes for the use in
chroot. Prudent users will also want to create static device nodes for
some essential devices to make sure that the system will always boot, even
if by mistake the kernel was compiled without udev or if the udev
configuration has been corrupted.
I don't think static device nodes will die anytime soon. And you just
argued yourself that the FHS mandates a /dev/MAKEDEV. And there's still
the educational aspect. Device nodes are an important part of UNIX. Maybe
they will be less frequently used in the future but they won't go away for
a long time.
If all the economists in the world were laid end to end,
they'd point in different directions.
More information about the lfs-dev