Hi Willy,
Quote:> I think this is a bad idea -- when doing a new port, it's easier to fill
> in the bits with the current scheme rather than with your proposed scheme.
The point about nay new port is that it is likely to be exactly the same as
one of the current ports as far as these defines and structures are
concerned. WIth the current scheme, you get exactly what happened with
PPC and PPC64 - i.e. they are identical with most of the other ports except
for a couple of defines which are only different because of an error.
There is no existing ABI that would be an excuse for them to be different.
With the new scheme, asm/fcntl.h consists of only the necessary
differences from the "norm" as defined by linux/fcntl.h.
Unjustified differences between the ports are a bad thing. For one,
it make the library maintainers job much harder ...
The longer term intent of my consolidation efforts is to lessen the
problems of all the port maintainers trying to keep up with each other
when bugs are fixed in (more or less generic) code in one port (usually
i386 ...). There are several bugs like this currently and I suspect
many that have not been discovered yet.
Quote:> There is one part which I like:
> -/* for old implementation of bsd flock () */
> -#define F_EXLCK 4 /* or 3 */
> -#define F_SHLCK 8 /* or 4 */
> All of these can go, nobody's been using them since kernel 2.0. I took
> out the last vestiges of them from locks.c earlier in 2.5. None of the
> BSDs have them either.
Wonderful, I will update my patch to remove them completely.
--
Cheers,
http://www.canb.auug.org.au/~sfr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
by