bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-inetutils] Re: route


From: Debarshi Ray
Subject: [bug-inetutils] Re: route
Date: Fri, 26 Sep 2008 23:59:04 +0530

>  It is very hard to merge things back; splitting
> things up when things do get large (100k bytes for a single file for
> example) is much easier.

You have easily side-stepped the issue of #ifdefs. If you are going to
include libnl interfacing code for the Linux kernel with PF_ROUTE code
for the BSDs, then you will end up with one huge file with mutually
exclusive blocks of #ifdefs. No portion of that file will be common.

What might be done, and I am not sure of it now, is to combine
bsd_show.c, bsd_add.c and bsd_delete.c into bsd.c and the same for the
linux_*.c files. But remember the *_add.c files don't just implement
add. They include variants like replace, prepend, append, etc.
currently offered by iproute2 on GNU/Linux systems.

This is entirely different from combining bsd_show.c and linux_show.c
into route_show.

> * inetutils/ifconfig/system/*.c
>
> The code here is for argument parsing, and output generation; very
> little of this code can be shared.

If only you realized that libnl (or PF_NELINK) interfacing code can
not be shared with ones interfacing with PF_ROUTE. That realization
will dawn once you do some ground work.

>   But the question is supporting different protocols (IPv4,
> IPv6), and different ways of setting the route tables (PF_ROUTE,
> PF_NETLINK, etc).  There is no good reason why all of this must be in
> seperate files, alot of the code can be shared,

No it can not be shared. It is a fact. PF_ROUTE and PF_NETLINK have
almost nothing in common when it comes to headers, macros, types,
functions. The fact they are both sockets don't matter either since we
are going to use libnl instead of PF_NETLINK directly.

> and it would be easier
> to maintain it; ping for example suffers from a "many small files"
> problem (we have two seperate versions one for IPv6 and one for IPv4),
> where one might forget to update one file, but not the other when
> changing an interfaces.

Rubbish. Some one just needed to abstract out the common parts into a
common backend and have them be just different clients using the same
backend. People are working on it now and sooner than later it will be
fixed.

IPv6 and IPv4 are much much more similar than libnl (or PF_NETLINK)
and PF_ROUTE. So this analogy does not hold.

>  Many bugs have been introduced in that
> manner.

Really? So what was the team of 4 maintainers doing about it for the
last so many years?

> * parted does something similar
>
> It is not important what parted does,

Why not? It is a live example how low-level interfacing with different
clients can be elegantly done. Another example of just hand-waving and
misinformed cheap talk.

Mind you Parted is widely used, and actively maintained. So your
maintenance concerns don't hold much water either.

> parted is also a single, large
> program.

Parted is NOT one single large program. It has a public library used
by other GNU and non-GNU programs and a command line frontend.

>  Our closest cousine is coreutils; the largest file there is
> some 150k bytes; but this is not what is the issue.  It is what _we_
> do; and we prefer few files.

We?

>  That you might find examples of the
> contrary is also not important,

Really?

> inetutils is a old project and has had
> multiple maintainers.

And I was one of them, and the only one actually did the hard work.
All that we now have are 4 people, 3 of whom are as silent as corpses
while one just keeps talking. I am really sorry about the mistake I
did by trusting Sergey/Jeff/you about doing a good job when your names
were recently added to the maintainers file.

> It also makes tracking history if you merge
> things back harder, we still use CVS (and there is no really good
> reason to switch yet), which is terrible when it comes to moving
> around files.

CVS is a centralized system making it easy for one person to control
or sensor write access to it. This is a big enough problem.

> My intention right now is to commit the last patch you sent (the one
> with only IPv4 support, which only uses PF_NETLINK) sometime next week
> as a single file (without the hook framework).

I have come far from that code and using a Git tree. route has already
been split into a library and the only change in the design is the use
of libnl instead of directly using PF_NETLINK. That will require
libroute to be under LGPLv3+.

BSD support is slowly getting into place. We can already display routes.

> I do no wish to spend more time on this issue, it is not a good way to
> spend our time and it is such a easy issue to solve; all I want is to
> see your continued contribution to inetutils, and have a good
> relationship again.

What you are saying makes no sense to me. It is not an easy thing to
solve when you just sit there wearing your "maintainer" hat and saying
"it is my way or the highway". I have been the most active Inetutils
in recent times by a very big margin and I have got route to work
single-handedly. Plus I am an ex co-maintainer who only gave up his
maintainership to avoid a 'too mny cooks will spoil the broth
situation'. All the opinions that you have expressed would only make
sense if you actually did some work on route/libroute and maintained
Inetutils. Just have a look at the buckets of warnings thrown by
recent versions of GCC, memory leaks, ping/ping6 issue that have
remained unattended for years and years. I took the initiative to
recruit hackers to do some of this work, while the rest of you just
sat there. Of course you did not sit there silently like the other
maintainers. You had talk and no code.

Now that some life has been kicked back into Inetutils please don't destroy it.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]