-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Alexander E. Patrakov wrote:
> 2007/11/17, Bryan Kadzban <[EMAIL PROTECTED]>:
>> A) We need to generate the rules, obviously. We don't want the
>> user to boot their LFS system for the first time without any rules
>> in existence, because they've already configured their NICs in
>> chapter 7.
>
> I disagree. We need to create, not necessarily generate, rules.
Right -- poor choice of words on my part. We need to get some set of
rules created, somehow. We don't have to use udev itself to do it.
(Of course, without udev, we don't get the comments in the file that
explain which device each rule applies to (e.g. PCI devices show the
PCI IDs and the driver name), if that matters.)
> The only cases one needs to consider are:
>
> 1) a wireless device that creates two interfaces (ath* and wlan*
> only) - instruct the reader to write a rule with ATTR{type}=="1"
There may be cases other than wireless devices where the type attribute
needs to be used. Or at least, the upstream persistent-net-generator
file seems to add that attribute for everything. I don't know if that
means that it's actually needed for anything other than this case,
though.
> 2) every other device that needs persistent rules (eth*, ra* and sta*
> only) - instruct the reader to write a rule without ATTR{type}
Looking at the upstream persistent-net-generator again, they create
rules for eth*, ath*, wlan*[0-9], ra*, and sta*, as you've said, but
also ctc*, lcs*, and hsi*. I don't know how many of those will ever
appear on an x86 machine, though.
(And you're right that nothing other than these get rules today.)
>> 2) We could fire up a copy of udevd inside chroot, and trigger all
>> the network-subsystem devices' uevents. We'd have to make sure the
>> new names don't actually get applied, otherwise we screw up the
>> host. There are also a few sockets (well, at least one) that udev
>> listens on that are exclusive: if a version of udevd is already
>> running on the host, we'd either have to kill it (leaving chroot to
>> do so) and restart it afterward (again leaving chroot), or make the
>> udevd-in-chroot not require that socket.
>
> I'd rather not do it, since this requires another "if" on the version
> of udev on the host (a bad thing for jhalfs),
I'm not sure what it would require from the host udev. The host udev
will either ignore the event, re-apply its existing name rule, or not be
running at all; it doesn't matter. The in-chroot udev will write the
rule(s) out to its file, but won't rename the interface(s), because the
interface name is machine-wide.
Unless I'm missing something?
Oh -- did you mean that killing the host's udevd would require another
if? It would, of course (so that's another strike against it), but I
don't think that starting up a secondary udevd inside chroot and killing
that process later would.
(I'd think that writing manual rules would be hard for jhalfs also,
right?)
> and running udevd inside the chroot increases our host kernel
> requirements.
This is most likely true. (It probably increases them to somewhere in
the neighborhood of 2.6.15 or so -- and if that's the minimum version,
it was released in January 2006, and came out between LFS 6.1 and 6.2.
Debian's udev package requires 2.6.15, that's where I got that version.)
I'm not sure what to do about it though, or if it's a problem. I'd
rather avoid it if possible, but I don't see any good way to do so yet.
(Going back to telling the user to write their own rules is one way to
do it, but IMO, we have most of the required stuff in place to write the
rules for the user already. Does it make sense to make them re-do
work?)
> debootstrap doesn't do this (it doesn't even install udev by
> default), you want to look at debian-installer.
Well, that explains why I couldn't find anything. :-) (Shows how much
I've done with Debian...)
> As far as I can see, udev in the debian installer creates persistent
> rules, so it would be straightforward to just copy them into the
> chroot, but I can't currently say whether this is what the installer
> actually does.
And I can't decipher how that whole system is put together (although
I've only been looking at it for a half hour or so), so I have no idea.
In any case, the installer is probably running a very similar kernel and
udev (version-wise) to what the final system will run, so they can get
away with stuff like a temp-rules solution (if it exists) more easily.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHQJpLS5vET1Wea5wRA+zvAKDTgROxvvC4RCSvc0GTagsoF4rR/ACgyJW4
zEAtlU+EzICicXWXUCGkbtc=
=eAy1
-----END PGP SIGNATURE-----
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
