On Thu, Apr 04, 2002 at 12:22:00AM -0500, Branden Robinson wrote:
> On Thu, Apr 04, 2002 at 03:04:17PM +1000, Anthony Towns wrote:
> > The kernel doesn't change ioctl numbers; they're actually competent at
> > maintaining their interfaces. OTOH, they don't consider their headers
> > such an interface, and they're happy to have them break randomly or not
> > work from userspace at all or anything.
> >
> > What we really should have is a nice low-level C library that encapsulates
> > such things and lets anyone use it...
>
> Fine and dandy, but what do I do in the meantime? I can guard each of
> the ioctl #defines with an #ifndef, but there's also a typedef thrown
> into the mix. I can't exactly do this:
>
> try {
> typedef struct {
> int context;
> unsigned int offset;
> unsigned int size;
> unsigned int free;
> } drm_sis_mem_t;
> } except redefinitionException {
> /* oh, that's all right, it's already defined */
> }
>
> It's because of this that I continue to feel that kernel interfaces are
> best defined by the kernel.
Pick a different name for the type, and use a #define to make the
following code pick it up transparently. Nothing revolutionary here.
> If the kernel headers aren't an interface, why do they exist? There
For the building of the kernel. Pretty much exclusively, as far as
they're concerned. Everywhere they're still pulled into glibc is a bug
no one's bothered to fix yet.
> appears to be a very large philosophical gulf here. The fact that the
Definitely, but nothing new to cope with.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
