> Everyone who uses <linux/foo.h> is going to be bitten.
Thanks, I got the idea, it's not new. It's just broken.
> This has been true for years, and will remain true,
> regardless of whether you put the proper #ifdef __KERNEL__
> incantations into the kernel headers.
I'm willing to live with the occasional breakage and to fix it as
required.
Besides, it's not that hard to avoid breakage. In the general case, that
is, with the current mess I agree it's a rather difficult task even to
decide where to stick your new definitions, let alone trying not to break
other things. Once sanitized though, I will be much better.
What I mean by sanitized: break headers into two halves, one which
contains only definitions and -- with appropriate #ifdef's -- can be
included by userspace, and one which contains static inline code, which
includes the first half and which should never ever be even looked at by
userspace. Breaking up fs.h would be the first step towards sanity. It's a
big job, maybe it's a 2.3 job and 2.1/2.2 should be patched as much as
possible with #ifdef's, though that will be ugly. We shouldn't have gotten
here to begin with.
> Thus, (1) it is a good idea to improve the kernel sources a bit,
Yup, that's all we're asking for. To be _allowed_ to fix it. I'm not
trying to say it's trivial, there is lots of cruft accumulated over the
years, and it only got worse in the 2.1 cycle. It can be done however, and
with the proper maintenance it can even stay more or less sane.
> but (2) you are wasting your time in the sense that a week
> or a month after you improved the includes something
> will be changed, and your programs will not compile anymore.
Fine, and the next day after I get a complaint, Linus will get a patch to
fix the headers. I prefer a "doesn't compile" error report, with a precise
reference to the place of the error, than a "doesn't work, whats wrong"
error report.
> That is not obvious at all. A grave mistake, in fact.
> The kernel presents an API to the outside world.
> Whatever the kernel does internally is none of your business,
And what exactly in my message referred to the kernel internals? I need
access to the API specs, as defined by system call prototypes, data
structures, symbolic constants and perhaps a few others I don't remember
right now.
> and will change from week to week. But the API remains fairly
> stable, with features being added but not changed.
I take this as an argument for keeping copies of the header files with the
application: since the API is stable, the application won't break on newer
kernels even if when compiled with headers from older kernels. Perhaps so,
but perhaps not. This is a test that somebody with more time on their
hands should run.
Regardless, this attitude towards kernel headers files is equivalent to a
"screw you losers" towards the people still using libc5. And while glibc
is arguably better and maintained, libc5 systems are still too numerous to
be just ignored. You can maybe do that with libc4 users (though I'm sure
David Parsons will disagree :-)), but not yet with libc5 users.
> You make the mistake of thinking that people run their programs
> under the same kernel as these programs are compiled under.
> But that is false. People switch back and forth between 2.0.* and 2.1.*,
> upgrade kernels every now and then, without recompiling all
> their utilities.
No, I'm not making this mistake, I'm very much aware of it. You however
are ignoring something very obvious: that the first thing people do when
something breaks after a kernel upgrade is to recompile the app.
> Indeed, most utilities from 1992 function fine today.
See hpa's reply. For that matter, please try to run the aout Legato
clients on a 2.1 system -- and watch your syslog. (I'm aware there are
newer clients, no need for pointers :-)) And they're not even that old, I
think they're from '94 or '95.
> Well-written source compiles under all sufficiently recent libraries
> and functions under all sufficiently recent kernels, including
> those of next week.
Sure. Again, libc5 and glibc, linux 2.0 and 2.1. This makes linux appear
as 4 different os's with different requirements, on the SAME architecture.
What a maintenance pleasure. But what I am talking about, you should be
aware of this, being the mount maintainer.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/