Jeff Garzik wrote:
>
> > > It would seem to be more sensible to do
> > >
> > > start_xmit()
> > > {
> > > ...
> > > if (!room for another packet)
> > > netif_stop_queue()
> > > }
> >
> > This doesn't give us a way to set dev->tbusy, which is required for all
> > pre-2.3 kernels.
>
> Why not? Maybe I am missing something. A 2.2.x implementation of
> stop_queue should set dev->tbusy's bit 0. That's what acenic and my
> kcompat software both do.
What I meant was, if the 2.2 driver did this:
start_xmit()
{
dev->tbusy = 1;
...
}
and the 2.3 driver does this:
start_xmit()
{
netif_stop_queue();
...
}
then the simple #define obviously perserves compatibility. But once
we remove the up-front netif_stop_queue() (which is quite legit because
some of the tbusy functionality is handled by dev->xmit_lock in 2.3)
then we have nowhere to put the 'tbusy = 1' macro.
Do we really think it's worth preserving the compatibility? I mean, the
2.3 series is where we place actual algorithmic enhancements, but doing
this in 2.2 is politically incorrect - 2.2 is supposed to be bugfixes
only (I think). So they diverge __by design__. If you want to put some
nifty new feature into your 2.3 driver and it's also a 2.2 driver then
you have a problem?
This approach places the onus on maintainers to be familiar with both
series, and to concientiously feed bugfixes back to 2.2 (and watch Alan
fumble them :)), but that's not too hard.
Which drivers are using kcompat24?
--
-akpm-
|