lkml.org 
[lkml]   [1999]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Kernel interface changes (was Re: cdrecord problems on
Date
> >No the model of binary kernel modules doesn't work. Thats not my problem.
> >Binary only compatibility is the cause of many of the problems in windows
>
> Unfortunately, I think it is a problem you have to take up and deal with.
> Recompiling sources for entire server setups in a live production
> environment because of a short->int conversion is nothing short of a
> nightmare for those of us who have to do it. For huge security holes I can

You aren't talking about recompiling sources for an entire server setup. You
are talking about rebuilding the modules. Most people do that routinely when
changing kernel anyway.

Also nobody is talking about doing it gratuitously. If its everyone suffers
or binary only modules they lose. I don't think any of us want to break binary
only modules for fun.

In 2.0.x I've no desire to change source compatibility unless I really have
no choice. I've no desire to change binary compatibility unless there is
no alternative. Torturing Derek Atkins is not my job description.

> I think either (a) slower and better documented releases of the kernel/C
> library or (b) a good binary compatibility layer that allows older kernel
> modules to still work would help alleviate this. Examples could be either

For the kernel you can write one. Go ahead. Its not trivial. Consider the
real cases where fixes had to be done. How do you back compatibly fix a
70K packet size into a 16bit length field ?
The cases where its trivial are ones it shouldnt have occured.

For user space glibc should be compatible. The LSB standards base project
is also a _binary_ standard. It documents API behaviour but for binary
compatibility. Glibc also split from the kernel headers to keep stability.
Glibc is a 32bit uid, large inode_t etc environment. When Linux kernel switches
to 32bit uid the glibc apps wont even notice.

So some of the work is being done and has been laid down very carefully.

If you want to make this work even better run a lot of 2.0 binaries on 2.2,
check they all still work. If not find out why. Similarly people should be
trying stuff like glibc 2.1 pre-releases with all their old binaries. Nothing
should break, if it does report it.

Alan


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [from the cache]
©2003-2011 Jasper Spaans