I'm looking at the changes in the asound.h file, and especially at
commit 512bbd6a85230f16389f0dd51925472e72fc8a91, and I've been
wondering if it's acceptable compatibility-wise. All the structures
passed through ioctl (and ALSA is 100% ioctl) have been renamed from
sndrv_* to snd_*. That breaks source compatibility but not binary
compatibility.
Ignoring the fact that the changelog comment utterly fails to mention
that part of the change, is keeping compatibility supposed to be
binary-only or source too?
OG.
On Mon, 2006-03-06 at 02:17 +0100, Olivier Galibert wrote:
> I'm looking at the changes in the asound.h file, and especially at
> commit 512bbd6a85230f16389f0dd51925472e72fc8a91, and I've been
> wondering if it's acceptable compatibility-wise. All the structures
> passed through ioctl (and ALSA is 100% ioctl) have been renamed from
> sndrv_* to snd_*. That breaks source compatibility but not binary
> compatibility.
only if you are "stupid" enough to use kernel headers in your userspace!
Which you shouldn't do normally
On Mon, Mar 06, 2006 at 08:52:48AM +0100, Arjan van de Ven wrote:
> On Mon, 2006-03-06 at 02:17 +0100, Olivier Galibert wrote:
> > I'm looking at the changes in the asound.h file, and especially at
> > commit 512bbd6a85230f16389f0dd51925472e72fc8a91, and I've been
> > wondering if it's acceptable compatibility-wise. All the structures
> > passed through ioctl (and ALSA is 100% ioctl) have been renamed from
> > sndrv_* to snd_*. That breaks source compatibility but not binary
> > compatibility.
>
> only if you are "stupid" enough to use kernel headers in your userspace!
> Which you shouldn't do normally
Does that mean it is the responsability of whoever packages the
headers for userspace consumption to rename the structs back? Or that
every application should come with its own copy of the kernel headers
it may need and be ready for massive source-level breakage when
rebasing?
I'm just trying to understand if we care about source compatibility
for userspace or not.
OG.
On 3/6/06, Olivier Galibert <[email protected]> wrote:
> On Mon, Mar 06, 2006 at 08:52:48AM +0100, Arjan van de Ven wrote:
> > On Mon, 2006-03-06 at 02:17 +0100, Olivier Galibert wrote:
> > > I'm looking at the changes in the asound.h file, and especially at
> > > commit 512bbd6a85230f16389f0dd51925472e72fc8a91, and I've been
> > > wondering if it's acceptable compatibility-wise. All the structures
> > > passed through ioctl (and ALSA is 100% ioctl) have been renamed from
> > > sndrv_* to snd_*. That breaks source compatibility but not binary
> > > compatibility.
> >
> > only if you are "stupid" enough to use kernel headers in your userspace!
> > Which you shouldn't do normally
>
> Does that mean it is the responsability of whoever packages the
> headers for userspace consumption to rename the structs back? Or that
> every application should come with its own copy of the kernel headers
> it may need and be ready for massive source-level breakage when
> rebasing?
>
> I'm just trying to understand if we care about source compatibility
> for userspace or not.
>
Userspace apps should not include kernel headers, period.
So, userspace applications really shouldn't care.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Mon, Mar 06, 2006 at 04:55:02PM +0100, Jesper Juhl wrote:
> Userspace apps should not include kernel headers, period.
> So, userspace applications really shouldn't care.
Please excuse me if I'm a little dense here, but the kernel headers
_define_ the userspace-kernel interface. If you don't have them or a
sanitized copy of them you just can't talk with the kernel at all.
OG.
On 3/6/06, Olivier Galibert <[email protected]> wrote:
> On Mon, Mar 06, 2006 at 04:55:02PM +0100, Jesper Juhl wrote:
> > Userspace apps should not include kernel headers, period.
> > So, userspace applications really shouldn't care.
>
> Please excuse me if I'm a little dense here, but the kernel headers
> _define_ the userspace-kernel interface. If you don't have them or a
> sanitized copy of them you just can't talk with the kernel at all.
>
Well, stuff like glibc, the alsa lib etc are exceptions, but the
exceptions are few and far between.
Random userspace apps should not use the kernel headers directly, they
should instead talk to things like glibc and let glibc handle the
userspace<->kernel bit.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Mon, 6 Mar 2006 17:15:12 +0100 Olivier Galibert wrote:
> On Mon, Mar 06, 2006 at 04:55:02PM +0100, Jesper Juhl wrote:
> > Userspace apps should not include kernel headers, period.
> > So, userspace applications really shouldn't care.
>
> Please excuse me if I'm a little dense here, but the kernel headers
> _define_ the userspace-kernel interface. If you don't have them or a
> sanitized copy of them you just can't talk with the kernel at all.
JJ should/could have said what to use instead.*
You should use glibc sanitized kernel headers.
Raw kernel headers are not appropriate or supported for use in
userspace.
*: similar to some replies like "No" without further explanation.
---
~Randy
> Please excuse me if I'm a little dense here, but the kernel headers
> _define_ the userspace-kernel interface.
I don't think so. The kernel headers define the API's that the
various kernel facilities present to each other, within the kernel.
The userspace-kernel interface is not really a simple interface
of procedures and types definable by a traditional C header.
It uses a variety of techniques, such as special calling conventions,
special files, and what not ... almost everything possible except
the simple call by one procedure of another on a common stack.
In the general case, we can do no more than document, from the
kernel side, what is the interface, and expect libraries and such
on the user side to wrap this up in a form palatable to C (and
other diverse) language uses.
Such header files as are useful to a userspace C programmer are
usually provided by the userspace library, for it is that library
that the application is linking with, not the kernel.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
Jesper Juhl wrote:
> Userspace apps should not include kernel headers, period.
> So, userspace applications really shouldn't care.
Yeah, but doesn't changing the names like this just make more work for
the guys that sanitize the kernel headers and have to stay
source-compatible with previous versions?
I mean, we shouldn't make extra work for other projects just for fun...
Chris