Request For Info - Hotplug Network Plan

Alexander E. Patrakov see at the.sig
Fri Jul 2 01:07:51 PDT 2004


Jim Gifford wrote:
> ----- Original Message ----- 
> From: "Alexander E. Patrakov" <see at the.sig>
> Newsgroups: lfs.dev
> To: <lfs-dev at linuxfromscratch.org>
> Sent: Thursday, July 01, 2004 9:44 PM
> Subject: Re: Request For Info - Hotplug Network Plan
> 
> 
> 
>>Jim Gifford wrote:
>>
>>>----- Original Message ----- 
>>>From: "Alexander E. Patrakov" <see at the.sig>
>>>
>>>>I will not move to entirely hotplug-driven setup for the following
>>>
>>>reasons:
>>>
>>>
>>>>1) I don't know how well it plays with IPX with current
>>>>(b)lfs-bootscripts. If the IPX settings are migrated to the main
>>>>ifconfig.eth0 file, this problem may go away
>>>>2) This doesn't play well with aliases. This problem will go away when
>>>>we push all aliases for eth0 into the main ifconfig.eth0 file.
>>>>3) Network coldplugging won't work at all for network cards compiled not
>>>>as modules, unless we write a completely custom /etc/hotplug/net.rc
> 
> file.
> 
>>>>The reason for network hotplug is merely to support Sharp Zaurus and
>>>>OpenZaurus users (I don't have Zaurus, but received a support request
>>>
>>>>from one of my friends).
>>>
>>>>-- 
>>>
>>>I'm against the idea myself. We only support an IP environment the last
> 
> time
> 
>>>I checked.
>>
>>You haven't checked this:
>>http://www.linuxfromscratch.org/blfs/view/cvs/basicnet/ncpfs.html
>>
>>
>>>IPRoute2 does do aliases, read the documentation.
>>
>>It does, and we are actually planning to use this package. The problem
>>is just to rewrite the "ifup" script.
>>
>>
>>>cold plugging of modules can be simplied added to modeprobe.conf
>>>alias ethx module name
>>
>>You have not read my mail well enough. I was talking exactly about
>>non-modular kernels. The bad thing is that the net hotplug event happens
>>when the kernel has not mounted the root filesystem yet and the hotplug
>>package has no chance to handle it.
>>
>>And your statement about alias ethx is valid only for net cards
>>undetectable by hotplug (e.g. old ne2000).
>>
>>
>>>As far as modifying the boot scripts, all hotplug is needed for is to
> 
> load
> 
>>>the driver, you don't need a special netrc with the configuration we are
>>>currently using. I'm using it myself with no issues, the only thing
> 
> hotplug
> 
>>>does is load my module for my nic.
>>
>>Your statement is valid for the current bootscripts. Looks like you have
>>not caught the context of this thread. The proposal was:
>>
>>Implement LFS specifics of network hotplug so that
>>/etc/hotplug/net.agent works and brings hotplugged interfaces up. Then
>>drop the S20network symlink and rely entirely upon hotplug to bring
>>interfaces up.
>>
>>I am _against_ the proposal above, but for correctness I had to mention
>>the (nonexistent in LFS) /etc/hotplug/net.rc file while argumenting my
>>viewpoint.
>>
>>I am _for_ the following proposal:
>>
>>Implement LFS specifics of network hotplug so that
>>/etc/hotplug/net.agent works and brings hotplugged interfaces up.
>>Provide enough infrastructure to ensure proper communication with e.g.
>>Sharp Zaurus over "usb0" interface in all cases involving usbnet being a
>>module or non-module and for hot and cold plug cases. Don't fail at boot
>>if Sharp Zaurus is not connected.
>>
>>-- 
> 
> It's not LFS it's BLFS and should stay in BLFS. LFS is a basic system, a
> basic system does not need what your proposing.
> 

LFS should provide a good base for BLFS, that's why the discussion.

To help me better understand your viewpoint, please answer the question 
below.

The hotplug package supports network hotplug (i.e., automatically 
bringing up the interface corresponding the hot-plugged USB network 
card) on RedHat and Gentoo. Currently we just delete the 
/etc/hotplug/net.agent file in LFS because our bootscripts don't have 
enough functionality. Should we:

A) Ignore the problem completely, say that network hotlug belongs to 
neither LFS nor BLFS, close the discussion, and (ideally) write a hint.
B) Leave the LFS situation as-is, correct it in BLFS, move this 
discussion to blfs-dev.
C) Just change the expected ifup script location in net.agent, ignoring 
the problems with aliases and IPX that will arise in BLFS. Correct the 
ifup script so that it will not bring up again interfaces that are 
already up. Optionally move this discussion into blfs-dev.
D) Solve the problem in LFS, so that IPX doesn't cause problems in BLFS. 
The discussion remains in lfs-dev.
E) Your own variant in the case I missed something

-- 
Alexander E. Patrakov
To get my address: echo '0!42!+/6 at 5-3.535.25' | tr \!-: a-z | tr n .



More information about the lfs-dev mailing list