linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: time for some drivers to be removed?
@ 2003-08-13 20:55 John Bradford
  2003-08-13 20:50 ` Adrian Bunk
  2003-08-13 20:55 ` Bill Davidsen
  0 siblings, 2 replies; 46+ messages in thread
From: John Bradford @ 2003-08-13 20:55 UTC (permalink / raw)
  To: bunk, davidsen; +Cc: alan, linux-kernel, wowbagger

> > > Interesting question - whatever I guess. We don't have an existing convention.
> > > How many drivers have we got nowdays that failing on just SMP ?
> > 
> > I 2.6.0-test2 tested on i386 with a .config that is without support for
> > modules and compiles as much as possible statically into the kernel.
> > Without claiming completeness, I found this way besides the complete Old
> > ISDN4Linux subsystem 36 drivers that compile due to cli/sti issues only
> > on UP.
>
> Should those be made to depend on SMP (not SMP) perhaps? They are probably
> high candidates for fixing if they work UP.

Especially since a lot of the time, 'works on UP, but not on SMP',
really means, 'broken on UP and SMP, but the bug is much more
difficult to trigger on UP'.

John.

^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: time for some drivers to be removed?
@ 2003-08-14  5:34 John Bradford
  0 siblings, 0 replies; 46+ messages in thread
From: John Bradford @ 2003-08-14  5:34 UTC (permalink / raw)
  To: bunk, john; +Cc: alan, davidsen, linux-kernel, wowbagger

> > > > > Interesting question - whatever I guess. We don't have an existing convention.
> > > > > How many drivers have we got nowdays that failing on just SMP ?
> > > > 
> > > > I 2.6.0-test2 tested on i386 with a .config that is without support for
> > > > modules and compiles as much as possible statically into the kernel.
> > > > Without claiming completeness, I found this way besides the complete Old
> > > > ISDN4Linux subsystem 36 drivers that compile due to cli/sti issues only
> > > > on UP.
> > >
> > > Should those be made to depend on SMP (not SMP) perhaps? They are probably
> > > high candidates for fixing if they work UP.
> > 
> > Especially since a lot of the time, 'works on UP, but not on SMP',
> > really means, 'broken on UP and SMP, but the bug is much more
> > difficult to trigger on UP'.
>
> Please reread my mail:
> "that compile due to cli/sti issues only on UP".
>
> This clearly disproves your theory.

I was talking about broken-on-SMP in general, not just this specific
case.

John.

^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: time for some drivers to be removed?
@ 2003-08-05 12:42 Mikael Pettersson
  2003-08-05 13:03 ` Adrian Bunk
  2003-08-05 16:35 ` Alan Cox
  0 siblings, 2 replies; 46+ messages in thread
From: Mikael Pettersson @ 2003-08-05 12:42 UTC (permalink / raw)
  To: alan; +Cc: linux-kernel

On 27 Jul 2003 21:56:11 +0100, Alan Cox wrote:
> On Sul, 2003-07-27 at 21:56, Adrian Bunk wrote:
> > That's no problem for me.
> > 
> > The only question is how to call the option that allows building only on
> > UP (e.g. cli/sti usage in the driver)? My suggestion was BROKEN_ON_SMP,
> > would you suggest OBSOLETE_ON_SMP?
> 
> Interesting question - whatever I guess. We don't have an existing convention.
> How many drivers have we got nowdays that failing on just SMP ?

ftape fails on SMP due to sti/save_flags/restore_flags removal.

My .config:

CONFIG_SMP=y
...
CONFIG_FTAPE=m
CONFIG_ZFTAPE=m
...
# CONFIG_FT_STD_FDC is not set
# CONFIG_FT_MACH2 is not set
# CONFIG_FT_PROBE_FC10 is not set
CONFIG_FT_ALT_FDC=y

#
# Consult the manuals of your tape drive for the correct settings!
#
CONFIG_FT_FDC_BASE=0x360
CONFIG_FT_FDC_IRQ=6
CONFIG_FT_FDC_DMA=2
CONFIG_FT_ALPHA_CLOCK=0

And the warnings:

drivers/char/ftape/lowlevel/fdc-io.c: In function `fdc_command':
drivers/char/ftape/lowlevel/fdc-io.c:221: warning: implicit declaration of function `restore_flags'
drivers/char/ftape/lowlevel/fdc-isr.c: In function `fdc_isr':
drivers/char/ftape/lowlevel/fdc-isr.c:1094: warning: implicit declaration of function `sti'
drivers/char/ftape/lowlevel/ftape-io.c: In function `ftape_sleep':
drivers/char/ftape/lowlevel/ftape-io.c:97: warning: implicit declaration of function `save_flags'
drivers/char/ftape/lowlevel/ftape-io.c:98: warning: implicit declaration of function `sti'
drivers/char/ftape/lowlevel/ftape-io.c:112: warning: implicit declaration of function `restore_flags'
drivers/char/ftape/lowlevel/ftape-format.c: In function `ftape_format_track':
drivers/char/ftape/lowlevel/ftape-format.c:135: warning: implicit declaration of function `restore_flags'
*** Warning: "sti" [drivers/char/ftape/lowlevel/ftape.ko] undefined!
*** Warning: "save_flags" [drivers/char/ftape/lowlevel/ftape.ko] undefined!
*** Warning: "restore_flags" [drivers/char/ftape/lowlevel/ftape.ko] undefined!

I have the HW so I can test patches if someone feels like fixing this.

/Mikael

^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: time for some drivers to be removed?
@ 2003-07-28  7:12 linux
  0 siblings, 0 replies; 46+ messages in thread
From: linux @ 2003-07-28  7:12 UTC (permalink / raw)
  To: linux-kernel

Yes, the term "obsolete" is a bit confusing to end-users.

When applied to a device driver, there are three separate definitions
that are at risk of being conflated:
- The hardware it supports is obsolete (EISA is obsolete)
- The code (which may still work) has been superseded by a new improved
  version (OSS is obsolete, Linus' original HD driver is obsolete)
- The code has not kept up with the kernel and no longer works with the
  current kernel.

The third category is what we're trying to identify here.

The risk of confusion is particularly large because often two of those
definitions apply at once.

If you want a suitably specific term for #3, I'd try CONFIG_BITROT.

I think that clearly conveys, in one word, "this code used to work, but
no longer does due to a lack of maintenance, and unless someone
breathes life back into it it will be given a decent burial."

(The other option that comes to mind is CONFIG_ORPHANED, which says
about the same thing, but might be unnecessarily insulting to a nominal
maintainer who hasn't been able to keep it up to date.  "Orphaned" implies
that nobody's trying.  "Bit rot" implies only a lack of *success*.)

^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: time for some drivers to be removed?
@ 2003-07-27 16:22 John Bradford
  0 siblings, 0 replies; 46+ messages in thread
From: John Bradford @ 2003-07-27 16:22 UTC (permalink / raw)
  To: bunk, wowbagger; +Cc: linux-kernel, rpjday

> That way, a busted item would not be built by default, and the item's 
> users would be motivated to correct it (and thus remove the stigma of 
> the BROKEN flag).

The point is, allyesconfig is NOT the default, and shouldn't ever be
treated as such.  The kernel resulting from an allyesconfig would
typically be too big to boot on i386 anyway.

> If an item stays BROKEN for too long, bu-bye! Obviously no-one cares 
> enough to fix it.

Or has access to the hardware to fix it.  For some rare hardware it
can be almost impossible to buy a replacement for any price, if it
breaks.

John.

^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: time for some drivers to be removed?
@ 2003-07-25 11:10 John Bradford
  0 siblings, 0 replies; 46+ messages in thread
From: John Bradford @ 2003-07-25 11:10 UTC (permalink / raw)
  To: john, ml; +Cc: diegocg, linux-kernel, rpjday

> > A CONFIG_KNOWN_BROKEN option is a good thing, in the case where,
> > E.G. a SCSI driver is broken, and will randomly corrupt data, but
> > otherwise compiles and appears to work.  
>
> I agree on that.
>
> Maybe I should make my point more clear. What bothers me is that a lot 
> of (early 2.4) kernel versions could easely be configured non-compiling. 
> Not just for exotic configurations, but also when building for an 
> average PC.
>
> That is very confusing (and anoying) for all kernel builders, as you can 
> not always easely tell if the kernel doesn't compile because of 
> misconfiguration or because of code errors.
>
> I hope that this can be avoided for 2.6.0. "Fixing" device drivers by 
> calling them obsolete, is not the right way. Because drivers that are 
> broken and fixed by nobody might not be obsolete.
>
> So for 2.6.0, I propose to only mark obsolete what is really obsolete. 
> Maybe everything that is broken since 2.2 and nobody complained about 
> it. Then, mark broken what is broken for some time and nobody is 
> (currenly) willing/able to fix.

Hmmm, maybe it's just me, but I think of obsolete as meaning something
that's due to be removed whether it works or not, because it's
functionality is no longer required.  I thought we had
CONFIG_EXPERIMENTAL for not sufficiently tested code.

It always used to be that with no CONFIG_EXPERIMENTAL tagged code
compiled in, it was very rare to get a compile failiure.  You could
rely on any kernel building, as long as you didn't touch
CONFIG_EXPERIMENTAL.

Unfortunately, what seems to have happened is that things that really
should be tagged with CONFIG_EXPERIMENTAL, are so desired by a lot of
users that they are being moved out of the experimental phase too
soon.

John.

^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: time for some drivers to be removed?
@ 2003-07-24 18:29 John Bradford
  2003-07-24 18:31 ` Robert P. J. Day
  2003-07-25 10:48 ` Bas Mevissen
  0 siblings, 2 replies; 46+ messages in thread
From: John Bradford @ 2003-07-24 18:29 UTC (permalink / raw)
  To: diegocg, rpjday; +Cc: linux-kernel, ml

> once upon a time, i suggested having more than one level of module
> "quality".  at the moment, some kernel code is marked as "EXPERIMENTAL"=
> ,
> but this is supported via a regular dependency when it doesn't really
> qualify as a dependency.  dependencies are typically used to refer to
> dependencies on other *code*, not some abstract level of goodness
> like "EXPERIMENTAL".
>
> perhaps it's time to add another category with values like OBSOLETE,
> DEPRECATED, EXPERIMENTAL, BROKEN(?) and so on.  by default, the
> quality would be regular, or something like that.

_NO_!!!

This is a _bad thing_, if a distribution wants to do it to their tree,
fine, but why add extra layers of complexity that a lot of devlopers
don't care about just so that the source tree 'looks nice'?  It's
absolutely pointless, and irritating for anybody actually trying to
work on the codebase.

> and in the end, while i know some folks don't think it's a big
> deal, i think doing a "make allyesconfig" really should work.

It's _counter productive_ just to bodge it so that make allyesconfig
works.  I _want_ it to _fail_ if the drivers are _broken_.

A CONFIG_KNOWN_BROKEN option is a good thing, in the case where,
E.G. a SCSI driver is broken, and will randomly corrupt data, but
otherwise compiles and appears to work.  Apart from that, it's a
complete waste of time to fiddle around with silly options that do
nothing but bloat the codebase and waste developers' time.

John.

^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: time for some drivers to be removed?
@ 2003-07-24 14:43 John Bradford
  2003-07-24 19:24 ` Brian Jackson
  0 siblings, 1 reply; 46+ messages in thread
From: John Bradford @ 2003-07-24 14:43 UTC (permalink / raw)
  To: linux-kernel, rpjday; +Cc: h

>   i've mentioned this before, but in a perfect world, should it
> be possible to build a release version of the kernel with
> "make allyesconfig".

Why?  The kernel wouldn't boot on i386 anyway, as it would be too
large.

> this is generally not possible, since there's always the occasional
> broken driver that just won't compile.

Just don't compile it in.

>   more to the point, there are drivers that seem to be perpetually
> broken.  as an example, the riscom8 driver has been borked for as 
> long as i can remember.  at some point, shouldn't something like
> this either be fixed or just removed?

I'm sure a patch to fix it would be accepted.

> what's the point of perpetually bundling a driver that doesn't even
> compile?

Some people might be interested in it.  Maybe somebody would like to
fix it, but can't buy the physical hardware for any price.  Maybe
everybody who has the hardware can't fix it because other kernel bugs
prevent them from using the latest kernels on their machines.  Why
remove it when it's doing no harm whatsoever?

John.

^ permalink raw reply	[flat|nested] 46+ messages in thread
* time for some drivers to be removed?
@ 2003-07-24 12:20 Robert P. J. Day
  2003-07-24 14:58 ` Alan Cox
  2003-07-27 15:31 ` Adrian Bunk
  0 siblings, 2 replies; 46+ messages in thread
From: Robert P. J. Day @ 2003-07-24 12:20 UTC (permalink / raw)
  To: Linux kernel mailing list


  i've mentioned this before, but in a perfect world, should it
be possible to build a release version of the kernel with
"make allyesconfig".  this is generally not possible, since there's
always the occasional broken driver that just won't compile.

  more to the point, there are drivers that seem to be perpetually
broken.  as an example, the riscom8 driver has been borked for as 
long as i can remember.  at some point, shouldn't something like
this either be fixed or just removed?  what's the point of 
perpetually bundling a driver that doesn't even compile?

rday

^ permalink raw reply	[flat|nested] 46+ messages in thread

end of thread, other threads:[~2003-08-14  5:26 UTC | newest]

Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-13 20:55 time for some drivers to be removed? John Bradford
2003-08-13 20:50 ` Adrian Bunk
2003-08-13 20:55 ` Bill Davidsen
  -- strict thread matches above, loose matches on Subject: below --
2003-08-14  5:34 John Bradford
2003-08-05 12:42 Mikael Pettersson
2003-08-05 13:03 ` Adrian Bunk
2003-08-05 13:35   ` Mikael Pettersson
2003-08-05 13:48     ` Adrian Bunk
2003-08-05 14:01       ` Mikael Pettersson
2003-08-06 10:06         ` Claus-Justus Heine
2003-08-09 19:40           ` Adrian Bunk
2003-08-05 16:35 ` Alan Cox
2003-08-05 18:47   ` Leopold Gouverneur
2003-07-28  7:12 linux
2003-07-27 16:22 John Bradford
2003-07-25 11:10 John Bradford
2003-07-24 18:29 John Bradford
2003-07-24 18:31 ` Robert P. J. Day
2003-07-24 19:31   ` Eli Carter
2003-07-25 10:48 ` Bas Mevissen
2003-07-24 14:43 John Bradford
2003-07-24 19:24 ` Brian Jackson
2003-07-24 12:20 Robert P. J. Day
2003-07-24 14:58 ` Alan Cox
2003-07-24 15:34   ` Bas Mevissen
2003-07-24 17:32     ` Diego Calleja García
2003-07-24 17:50       ` Robert P. J. Day
2003-07-24 19:16         ` Diego Calleja García
2003-07-24 19:43           ` Robert P. J. Day
2003-07-24 18:02       ` Samuel Flory
2003-07-24 19:07     ` Alan Cox
2003-07-25 10:48       ` Bas Mevissen
2003-07-27 15:31 ` Adrian Bunk
2003-07-27 15:59   ` David D. Hagood
2003-07-27 16:18     ` Adrian Bunk
2003-07-27 16:40     ` Alan Cox
2003-07-27 17:00       ` Adrian Bunk
2003-07-27 18:45       ` David D. Hagood
2003-07-27 20:40         ` Alan Cox
2003-07-27 20:56           ` Adrian Bunk
2003-07-27 20:56             ` Alan Cox
2003-07-28  2:23               ` Herbert Pötzl
2003-07-29 19:33               ` Adrian Bunk
2003-08-13 20:16                 ` Bill Davidsen
2003-08-09 18:04   ` David Woodhouse
2003-08-09 19:36     ` Adrian Bunk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).