[RFC] Backward compatibility and WAN netdev configuration

[RFC] Backward compatibility and WAN netdev configuration

[Krzysztof Halasa]

Hi,

I'm considering some changes/additions to my generic HDLC (WAN) code.

What do you think about:
a) Currently it consists of mid-layer WAN protocols single module (Cisco
   HDLC, FR etc.) + low-level hardware HDLC card driver (C101, N2, PCI200SYN
   etc.). I'm thinking about splitting the protocol module into separate
   modules - it would make them independent, users would be able to
   load, say, FR without PPP or X.25 and underlying syncppp, lapb etc.
   From the technical POV it would be superior to current code but it
   would require sysadmins to change modprobe.conf, add another modprobe
   or something like that. Not a real problem but the upgrade can't be
   automatic.

b) I'm currently using a dedicated "sethdlc" tool for configuring WAN
   devices (both physical parameters like clocking, speeds etc. and
   protocol parameters/selection). It uses ioctl(). I'm thinking about
   switching configuration interface to sysfs. That would render the
   old ioctl interface obsolete.
   It would mean much better flexibility, and (when the HDLC ioctl
   interface is removed in a year or so) would simplify the code.

   I'm not sure about using sysfs for net device configuration, though.
   Of course, it would make sysfs mandatory for generic HDLC users.

I'd aim at making changes to ~ 2.6.18.

Opinions?
-- 
Krzysztof Halasa

Re: [RFC] Backward compatibility and WAN netdev configuration

[Marco d'Itri]

On Feb 01, Krzysztof Halasa <khc@pm.waw.pl> wrote:

> a) Currently it consists of mid-layer WAN protocols single module (Cisco
>    HDLC, FR etc.) + low-level hardware HDLC card driver (C101, N2, PCI200SYN
>    etc.). I'm thinking about splitting the protocol module into separate
>    modules - it would make them independent, users would be able to
>    load, say, FR without PPP or X.25 and underlying syncppp, lapb etc.
>    From the technical POV it would be superior to current code but it
>    would require sysadmins to change modprobe.conf, add another modprobe
>    or something like that. Not a real problem but the upgrade can't be
>    automatic.
Why you cannot support autoloading the modules when a specific protocol
is needed?

-- 
ciao,
Marco

Re: [RFC] Backward compatibility and WAN netdev configuration

[Krzysztof Halasa]

md@Linux.IT (Marco d'Itri) writes:

> Why you cannot support autoloading the modules when a specific protocol
> is needed?

I probably could but it would complicate things a bit - currently only
the protocol module knows about existence of its protocol.

I will look at it, though. Thanks.
-- 
Krzysztof Halasa

Re: [RFC] Backward compatibility and WAN netdev configuration

[Stephen Hemminger]

On Wed, 01 Feb 2006 19:33:47 +0100
Krzysztof Halasa <khc@pm.waw.pl> wrote:

> md@Linux.IT (Marco d'Itri) writes:
> 
> > Why you cannot support autoloading the modules when a specific protocol
> > is needed?
> 
> I probably could but it would complicate things a bit - currently only
> the protocol module knows about existence of its protocol.
> 
> I will look at it, though. Thanks.

The modern way is to not have any entries in modprobe.conf, and do all
the module loading via kernel module_aliases. Modprobe.conf is then
reserved for handling workarounds for special cases
-- 
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger