I agree with this in principle, but it is rife with gotcha's...
I've been trying to work with Darren Rush's "IP Filter" package that
includes some nice stateful filtering. I got it patched into 2.0.33
on RedHat 4.2 and RedHat 4.1 ok. Doing the same thing on RedHat 5.0 with
glibc was an incredible nightmare! He has somewhere between 1/2 dozen and
a dozen source files which are compiled into both the kernel space module
and into the utilities. Right or wrong, that is the path he chose to keep
from writing duplicate code in both spaces! I ended up with "Mondo #ifdef's"
around entire "include" blocks for those files and two largely different
set's of includes depending on the "#if defined(LINUX) && defined(__KERNEL__)"
I also ran into some similar nasties with smbmount / smbmnt in the
Samba package. The smbmount program needed a define from one of the smbfs
headers and immediately impaled itself on conflicting defines for "dirent"
between the kernel and glibc. It didn't NEED either definition - it didn't
even use dirent! I still had to edit the Linux include files to work around
that gotcha. Don't know what the long term solution to that problem should be.
Yes, yes, yes... I know these are very rare special cases and that's
why I agree with the overall glibc idea in principle. There are just going
to be those times where, for one reason or another, it just didn't work out
the way we might have hoped. And if it makes it easier for the vast majority
of applications to be ported or developed for Linux - GREAT! That's most
definitely a good thing. Improving portability is also a good thing. There
are just going to be some applications where it comes back to bite us on
the .....
> And by the way: what number of programs (and what percantage) do we
> talk about? These are mainly problems for programs which are close to
> the kernel and written by the same people who wrote the kernel stuff.
> Of course you've used the same names etc which I fully can understand
> for a first implementation. But ince the programs are released to the
> world these problems should have been fixed and since the nubmer is
> quite low there is no such problem.
Agreed here. It just should not have been so painful... A
well publicized "porting guide" ala the old thing from Sun that they
put out about porting from SunOS to Solaris. I have this feeling of
Deja Vue here. This is a lot like that effort. Except, I don't recall
seeing much warning that this train was heading down this track this time.
Maybe I just wasn't following the right threads on the right lists, but
glibc on RedHat 5.0 caught me and a number of other people totally off guard.
> ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
> Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
> Cygnus Solutions `--' drepper at cygnus.com `------------------------
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu