On Thu, Apr 04, 2002 at 08:55:22PM +0200, Michel Dänzer wrote:
> > This means forking from XFree86 upstream in a way that I'm not entirely
> > comfortable with. Is there anyone around who is familiar with DRM
> > innards who would be willing to work with me and upstream to get this
> > fix impleme
On Thu, 2002-04-04 at 20:34, Branden Robinson wrote:
> On Thu, Apr 04, 2002 at 10:37:52AM +0100, Philip Blundell wrote:
> > About the only thing you can do is to discontinue use of the kernel
> > headers altogether and provide your own, unconditional, definitions
> > (with different names if there
On Thu, Apr 04, 2002 at 10:37:52AM +0100, Philip Blundell wrote:
> About the only thing you can do is to discontinue use of the kernel
> headers altogether and provide your own, unconditional, definitions
> (with different names if there is any danger that the kernel's version
> of them might becom
On Thu, 2002-04-04 at 05:59, Branden Robinson wrote:
> If the kernel revs in such a way as to break
> ioctl numbers, there's no userland way around it, is there?
No. On the other hand, this virtually never happens. The kernel people
are usually quite disciplined about not making changes that wou
On Thu, Apr 04, 2002 at 12:22:00AM -0500, Branden Robinson wrote:
>
> It's because of this that I continue to feel that kernel interfaces are
> best defined by the kernel.
>
> If the kernel headers aren't an interface, why do they exist? There
> appears to be a very large philosophical gulf here
On Thu, Apr 04, 2002 at 12:16:30AM -0500, Ben Collins wrote:
> >
> > What we really should have is a nice low-level C library that encapsulates
> > such things and lets anyone use it...
> >
>
> All we really need is a master ioctl header that defines the numbers. It
> would be Debian specific, b
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 interfa
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 users
>
> What we really should have is a nice low-level C library that encapsulates
> such things and lets anyone use it...
>
All we really need is a master ioctl header that defines the numbers. It
would be Debian specific, but what the hell.
--
Debian - http://www.debian.org/
Linux 1394 - htt
On Wed, Apr 03, 2002 at 11:59:36PM -0500, Branden Robinson wrote:
> On Wed, Apr 03, 2002 at 11:34:26PM -0500, Branden Robinson wrote:
> > Apparently, if the Linux kernel driver guys renumber some ioctls, the
> > right thing is for everybody's apps to break instantly.
> Err, brainfart -- scratch tha
On Wed, Apr 03, 2002 at 11:34:26PM -0500, Branden Robinson wrote:
> Apparently, if the Linux kernel driver guys renumber some ioctls, the
> right thing is for everybody's apps to break instantly.
Err, brainfart -- scratch that point. Obviously this happens no matter
where they're defined, because
On Wed, Apr 03, 2002 at 09:42:24PM -0500, Jack Howarth wrote:
> Hello,
>Could someone explain to me the point of releasing
> Xfree86 4.1.0-15 as is when clearly patch #065 was
> going to break builds on most non-intel arches?
Actually, the patch was applied to FIX a problem with building xfre
Opps...that bug report associated with this
problem is 141116 not 141114...sorry.
Jack
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hello,
Could someone explain to me the point of releasing
Xfree86 4.1.0-15 as is when clearly patch #065 was
going to break builds on most non-intel arches?
* patch #065: raped again by Herbert Xu and Ben Collins; you're not
"supposed to" Build-Depend on a kernel package and at the same
14 matches
Mail list logo
