3:48 a.m.
Why is the define URB_ASYNC_UNLINK missing in include/linux/usb.h?
It is present in the 2.6.13 vanilla kernel and it is needed to compile a
linuxant driverloader module.
3:57 a.m.
On Thu, Sep 22, 2005 at 10:48:56AM +0200, DI Mario Bruckschwaiger wrote:
Why is the define URB_ASYNC_UNLINK missing in include/linux/usb.h?
It is present in the 2.6.13 vanilla kernel and it is needed to compile a
linuxant driverloader module.
Because the rawhide kernel isn't 2.6.13
It's a 2.6.14rc2 kernel right now, which has this symbol removed.
Dave
6:07 a.m.
Dave Jones wrote:
On Thu, Sep 22, 2005 at 10:48:56AM +0200, DI Mario Bruckschwaiger
wrote:
> Why is the define URB_ASYNC_UNLINK missing in include/linux/usb.h?
> It is present in the 2.6.13 vanilla kernel and it is needed to compile a
> linuxant driverloader module.
Because the rawhide kernel isn't 2.6.13
It's a 2.6.14rc2 kernel right now, which has this symbol removed.
Dave
Ah, I see. But that's confusing, isn't it?
12:49 p.m.
On Thu, Sep 22, 2005 at 01:07:04PM +0200, DI Mario Bruckschwaiger wrote:
Dave Jones wrote:
>On Thu, Sep 22, 2005 at 10:48:56AM +0200, DI Mario Bruckschwaiger wrote:
> > Why is the define URB_ASYNC_UNLINK missing in include/linux/usb.h?
> > It is present in the 2.6.13 vanilla kernel and it is needed to compile
> a > linuxant driverloader module.
>
>Because the rawhide kernel isn't 2.6.13
>It's a 2.6.14rc2 kernel right now, which has this symbol removed.
Ah, I see. But that's confusing, isn't it?
Not really. rawhide is always the 'upstream snapshot of the day'.
Or close to it.
Putting 'rc' or '-git' into the rpm name would probably cause havoc
with rpm versioning.
Dave
2:13 p.m.
On Thu, 2005-09-22 at 13:49 -0400, Dave Jones wrote:
On Thu, Sep 22, 2005 at 01:07:04PM +0200, DI Mario Bruckschwaiger
wrote:
> Dave Jones wrote:
> >On Thu, Sep 22, 2005 at 10:48:56AM +0200, DI Mario Bruckschwaiger wrote:
> > > Why is the define URB_ASYNC_UNLINK missing in include/linux/usb.h?
> > > It is present in the 2.6.13 vanilla kernel and it is needed to compile
> > a > linuxant driverloader module.
> >
> >Because the rawhide kernel isn't 2.6.13
> >It's a 2.6.14rc2 kernel right now, which has this symbol removed.
>
> Ah, I see. But that's confusing, isn't it?
Not really. rawhide is always the 'upstream snapshot of the
day'.
Or close to it.
Oh... I see. So kernel-2.6.13-1.1565 is really 2.6.14rc2 (I see the
2.6.14 patches there in the source directory now). So, any hope of
seeing this filter down into FC4 eventually? There's been a few
requests for 2.6.13.x and there's at least one USB patch to this kernel
that improves the performance of USB ACM modems beyond the currently
roughly 64K baud cap (I've got several ISDN modems that need at least
128K baud each). That patch doesn't patch the 2.6.12 kernel cleanly.
Putting 'rc' or '-git' into the rpm name would
probably cause havoc
with rpm versioning.
There may not be a good solution but it is definitely confusing.
Dave
Mike
--
Michael H. Warfield | (770) 985-6132 | mhw(a)WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
4:31 p.m.
On Thu, Sep 22, 2005 at 03:13:08PM -0400, Michael H. Warfield wrote:
> Not really. rawhide is always the 'upstream snapshot of the
day'.
> Or close to it.
Oh... I see. So kernel-2.6.13-1.1565 is really 2.6.14rc2 (I see the
2.6.14 patches there in the source directory now). So, any hope of
seeing this filter down into FC4 eventually?
I had this idea a while back to increase the testing that usptream -rc
kernels get, by pushing them out to updates-testing. It's something
that sounds great on paper, but in reality would be a total disaster.
2.6.14rc2 doesn't even boot on half my test boxes right now, and from
the feedback from folks at the office and bugzilla, it's pretty grim
and nowhere near ready for general consumption.
2.6.13 was pretty much the same way. For quite a few people, it was
unusable without the PCI fixes that went into 2.6.13.1
I've cooked up a 2.6.13.2 test kernel that I'll be pushing out to
fc4-updates-testing in the next few hours. It'll likely need
quite a bit more work before its ready for updates-final too,
but it gives people something to play with until its ready.
Dave
5:16 p.m.
On Thu, 2005-09-22 at 17:31 -0400, Dave Jones wrote:
On Thu, Sep 22, 2005 at 03:13:08PM -0400, Michael H. Warfield wrote:
> > Not really. rawhide is always the 'upstream snapshot of the day'.
> > Or close to it.
>
> Oh... I see. So kernel-2.6.13-1.1565 is really 2.6.14rc2 (I see the
> 2.6.14 patches there in the source directory now). So, any hope of
> seeing this filter down into FC4 eventually?
I had this idea a while back to increase the testing that usptream
-rc
kernels get, by pushing them out to updates-testing. It's something
that sounds great on paper, but in reality would be a total disaster.
2.6.14rc2 doesn't even boot on half my test boxes right now, and
from
the feedback from folks at the office and bugzilla, it's pretty grim
and nowhere near ready for general consumption.
2.6.13 was pretty much the same way. For quite a few people, it was
unusable without the PCI fixes that went into 2.6.13.1
I've cooked up a 2.6.13.2 test kernel that I'll be pushing
out to
fc4-updates-testing in the next few hours. It'll likely need
quite a bit more work before its ready for updates-final too,
but it gives people something to play with until its ready.
Sooner I can lay my hands on that the better. I need to roll this
usb-cdc-acm performance patch into that and get it on a box with several
ISDN modems. The whole upgrade to 2.6.14rc2 seems to be a real mess
(re: thread I'm in the middle of over on fedora-devel over the kudzu
catch-22). As soon as that's available, I'll try giving it a hammering.
Dave
One BIG question...
This is vis-a-vis the kudzu conflict vs 2.6.13 kernels being beat on
over on the fedora-devel list. On what side of the fence will this
2.6.13.2 kernel fall? Does it conflict with the kudzu currently with
the 2.6.12 kernels? Will this 2.6.13.2 kernel provide us with a
stepping stone past the kernel <-> kudzu catch-22 critical dependency?
The 2.6.13-1.1567 kernel (which is really the 2.6.14rc2 kernel)
conflicts with the existing kudzu. The kudzu from rawhide conflicts
with any kernel < 2.6.13. Sooo... Is it real or is it memorex? Is it
really < 2.6.13 or is it really < 2.6.14rc2? What happens in the
boundary condition we appear to be approaching?
Mike
--
Michael H. Warfield | (770) 985-6132 | mhw(a)WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
5:33 p.m.
On Thu, Sep 22, 2005 at 06:16:13PM -0400, Michael H. Warfield wrote:
This is vis-a-vis the kudzu conflict vs 2.6.13 kernels being beat
on
over on the fedora-devel list. On what side of the fence will this
2.6.13.2 kernel fall? Does it conflict with the kudzu currently with
the 2.6.12 kernels? Will this 2.6.13.2 kernel provide us with a
stepping stone past the kernel <-> kudzu catch-22 critical dependency?
The 2.6.13-1.1567 kernel (which is really the 2.6.14rc2 kernel)
conflicts with the existing kudzu. The kudzu from rawhide conflicts
with any kernel < 2.6.13. Sooo... Is it real or is it memorex? Is it
really < 2.6.13 or is it really < 2.6.14rc2? What happens in the
boundary condition we appear to be approaching?
The conflict only exists in rawhide. The 2.6.13.2 kernel is an FC4 update,
so completely unrelated.
Dave
6791
days inactive
6791
days old
7 comments
3 participants
participants (3)
-
Dave Jones -
DI Mario Bruckschwaiger -
Michael H. Warfield