Discussion:
[patch] modular ifconfig
(too old to reply)
David Young
2008-06-25 22:32:02 UTC
Permalink
I have created a patch that lets us add/remove features from ifconfig,
such as support for various address families (inet, inet6, iso, atalk) and
protocols (802.11, 802.3ad, CARP), simply by trimming the list of sources
(SRCS) in the Makefile. This helps one customize ifconfig for an embedded
device or for install media, and it eliminates a lot of grotty #ifdef'age.
Now, the ifconfig syntax and semantics are finalized at run-time using
the constructor routines in each address-family/protocol module.

The patch is at
<ftp://cuw.ojctech.com/users/netbsd-b17835c3/ifconfig.modularize2>.

In principle, a tiny ifconfig binary could load virtually all of its
syntax from shared objects "just in time." I don't plan to take ifconfig
in that direction.

I extracted a lot of common code into subroutines, too, in order to
shrink the ifconfig binary a bit. I have made all of the address
families share a lot of code for address addition/replacement/removal.
That probably broke atalk and iso, despite my best efforts.

I have also extracted an include file, Makefile.inc, containing the
make-fu that both ifconfig and x_ifconfig share.

(BTW, I noticed that distrib/utils/x_ifconfig/ requires WARNS=4 to build,
but sbin/ifconfig/ does not. I could not explain the discrepancy in
several minutes looking, so I left in WARNS=4.)

Dave
--
David Young OJC Technologies
***@ojctech.com Urbana, IL * (217) 278-3933 ext 24

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Jason Thorpe
2008-06-26 00:37:45 UTC
Permalink
Post by David Young
In principle, a tiny ifconfig binary could load virtually all of its
syntax from shared objects "just in time." I don't plan to take ifconfig
in that direction.
It shouldn't load them "just in time", it could just load a list of
them when it starts up. That definitely is a direction we could /
should go.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David Young
2008-06-26 21:51:14 UTC
Permalink
Post by Jason Thorpe
Post by David Young
In principle, a tiny ifconfig binary could load virtually all of its
syntax from shared objects "just in time." I don't plan to take ifconfig
in that direction.
It shouldn't load them "just in time", it could just load a list of
them when it starts up. That definitely is a direction we could /
should go.
I don't think I understand the use-case you have in mind. Where does
the list come from? If the list is static, why not link all of the
modules, always?

Dave
--
David Young OJC Technologies
***@ojctech.com Urbana, IL * (217) 278-3933 ext 24

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Jason Thorpe
2008-06-27 07:07:26 UTC
Permalink
Post by David Young
I don't think I understand the use-case you have in mind. Where does
the list come from? If the list is static, why not link all of the
modules, always?
The modules live in directory, and you enumerate the directory
looking, loading each one that's there.
Post by David Young
Dave
--
David Young OJC Technologies
-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Darren Reed
2008-07-01 10:56:18 UTC
Permalink
Post by Jason Thorpe
Post by David Young
I don't think I understand the use-case you have in mind. Where does
the list come from? If the list is static, why not link all of the
modules, always?
The modules live in directory, and you enumerate the directory
looking, loading each one that's there.
I'd like to see this too...

I wonder if it makes sense to adapt netstat to this model?
Or one slightly more complex, that deals with both families
(-f inet) and protocols (-p tcp)?

I'd almost suggest that the family blob that is delivered contains
interfaces for both ifconfig and netstat, but that might be going
just a bit too far.

I don't think there are any other networking commands that
come to mind as benefitting from this style of backend?

Darren


Darren


Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Hubert Feyrer
2008-07-01 10:58:17 UTC
Permalink
Post by Darren Reed
I don't think there are any other networking commands that
come to mind as benefitting from this style of backend?
route(8)?


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
George Michaelson
2008-07-02 03:22:28 UTC
Permalink
Post by Hubert Feyrer
I don't think there are any other networking commands that come to mind
as benefitting from this style of backend?
route(8)?
- Hubert
wlanctl?

-G


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Daniel Carosone
2008-07-02 03:53:01 UTC
Permalink
Post by George Michaelson
Post by Hubert Feyrer
I don't think there are any other networking commands that come to mind
as benefitting from this style of backend?
route(8)?
wlanctl?
Nice suggestions, but if a whole-sale refactoring of these tools is in
order, heading towards proplib rather than loads-of-ioctl's and
special-code-to-call-them would probably be better. That still leaves
the question of "syntax modules", but that more restricted space could
be handled with some grammar specifier rule files, or maybe/mostly by
direct inspection of the proplib interface offered by the kernel.

just since we're passing around idle design mandates.. :-)

--
Dan.

Loading...