linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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-08-05 12:42 time for some drivers to be removed? Mikael Pettersson
@ 2003-08-05 13:03 ` Adrian Bunk
  2003-08-05 13:35   ` Mikael Pettersson
  2003-08-05 16:35 ` Alan Cox
  1 sibling, 1 reply; 46+ messages in thread
From: Adrian Bunk @ 2003-08-05 13:03 UTC (permalink / raw)
  To: Mikael Pettersson, heine; +Cc: alan, linux-kernel

On Tue, Aug 05, 2003 at 02:42:28PM +0200, Mikael Pettersson wrote:
> 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.
>...
> I have the HW so I can test patches if someone feels like fixing this.

There seems to be an upgrade f the ftape code available at [1], but I 
haven't investigated on the status or plans to integrate it into 2.6.

@Claus-Justus:
Could you comment on this?

> /Mikael

cu
Adrian

[1] http://www.instmath.rwth-aachen.de/~heine/ftape/

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


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

* Re: time for some drivers to be removed?
  2003-08-05 13:03 ` Adrian Bunk
@ 2003-08-05 13:35   ` Mikael Pettersson
  2003-08-05 13:48     ` Adrian Bunk
  0 siblings, 1 reply; 46+ messages in thread
From: Mikael Pettersson @ 2003-08-05 13:35 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Mikael Pettersson, heine, alan, linux-kernel

Adrian Bunk writes:
 > On Tue, Aug 05, 2003 at 02:42:28PM +0200, Mikael Pettersson wrote:
 > > 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.
 > >...
 > > I have the HW so I can test patches if someone feels like fixing this.
 > 
 > There seems to be an upgrade f the ftape code available at [1], but I 
 > haven't investigated on the status or plans to integrate it into 2.6.

ftape-4.04? That's been a non-integrated external package for ages and ages.
I doubt there's been any updates in it for 2.5/2.6 kernels.

I used to use ftape-4 snapshots in late 2.1 and most 2.2 kernels, but patch
maintenance overhead made me go back to the kernel's ftape before 2.4.0.

Given how few still use these antiques (my "fast" Conner/Seagate drive gives
150KBps backup speed, wow!) I think simply maintaining status quo is the most
reasonable use of peoples' time.

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

* Re: time for some drivers to be removed?
  2003-08-05 13:35   ` Mikael Pettersson
@ 2003-08-05 13:48     ` Adrian Bunk
  2003-08-05 14:01       ` Mikael Pettersson
  0 siblings, 1 reply; 46+ messages in thread
From: Adrian Bunk @ 2003-08-05 13:48 UTC (permalink / raw)
  To: Mikael Pettersson; +Cc: heine, alan, linux-kernel

On Tue, Aug 05, 2003 at 03:35:10PM +0200, Mikael Pettersson wrote:
> 
> ftape-4.04? That's been a non-integrated external package for ages and ages.
> I doubt there's been any updates in it for 2.5/2.6 kernels.
>...

Is there a good reason why it wasn't / isn't integrated?

> Given how few still use these antiques (my "fast" Conner/Seagate drive gives
> 150KBps backup speed, wow!) I think simply maintaining status quo is the most
> reasonable use of peoples' time.

The problem is that 2.6 doesn't maintain the status quo - it's no longer 
possible to use ftape on a SMP workstation.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


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

* Re: time for some drivers to be removed?
  2003-08-05 13:48     ` Adrian Bunk
@ 2003-08-05 14:01       ` Mikael Pettersson
  2003-08-06 10:06         ` Claus-Justus Heine
  0 siblings, 1 reply; 46+ messages in thread
From: Mikael Pettersson @ 2003-08-05 14:01 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Mikael Pettersson, heine, alan, linux-kernel

Adrian Bunk writes:
 > On Tue, Aug 05, 2003 at 03:35:10PM +0200, Mikael Pettersson wrote:
 > > 
 > > ftape-4.04? That's been a non-integrated external package for ages and ages.
 > > I doubt there's been any updates in it for 2.5/2.6 kernels.
 > >...
 > 
 > Is there a good reason why it wasn't / isn't integrated?

Claus-Justus (the official maintainer) never bothered doing it.

 > > Given how few still use these antiques (my "fast" Conner/Seagate drive gives
 > > 150KBps backup speed, wow!) I think simply maintaining status quo is the most
 > > reasonable use of peoples' time.
 > 
 > The problem is that 2.6 doesn't maintain the status quo - it's no longer 
 > possible to use ftape on a SMP workstation.

Yes, but fixing that one problem is probably a lot less work than merging ftape-4.

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

* Re: time for some drivers to be removed?
  2003-08-05 12:42 time for some drivers to be removed? Mikael Pettersson
  2003-08-05 13:03 ` Adrian Bunk
@ 2003-08-05 16:35 ` Alan Cox
  2003-08-05 18:47   ` Leopold Gouverneur
  1 sibling, 1 reply; 46+ messages in thread
From: Alan Cox @ 2003-08-05 16:35 UTC (permalink / raw)
  To: Mikael Pettersson; +Cc: Linux Kernel Mailing List

On Maw, 2003-08-05 at 13:42, Mikael Pettersson wrote:
> 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.

The -ac tree has some stuff for this sitting in it but I've not been able to
find a tester..


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

* Re: time for some drivers to be removed?
  2003-08-05 16:35 ` Alan Cox
@ 2003-08-05 18:47   ` Leopold Gouverneur
  0 siblings, 0 replies; 46+ messages in thread
From: Leopold Gouverneur @ 2003-08-05 18:47 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel

On Tue, Aug 05, 2003 at 05:35:38PM +0100, Alan Cox wrote:
> > 
> > ftape fails on SMP due to sti/save_flags/restore_flags removal.
> 
> The -ac tree has some stuff for this sitting in it but I've not been able to
> find a tester..

I would be happy to test (I have the hardware :( ) but your patch
don't compile due to sti and restore_flags still in ftape/lowlevel

Thanks anyway


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

* Re: time for some drivers to be removed?
  2003-08-05 14:01       ` Mikael Pettersson
@ 2003-08-06 10:06         ` Claus-Justus Heine
  2003-08-09 19:40           ` Adrian Bunk
  0 siblings, 1 reply; 46+ messages in thread
From: Claus-Justus Heine @ 2003-08-06 10:06 UTC (permalink / raw)
  To: Mikael Pettersson; +Cc: Adrian Bunk, heine, alan, linux-kernel



Mikael Pettersson schrieb:
> Adrian Bunk writes:
>  > On Tue, Aug 05, 2003 at 03:35:10PM +0200, Mikael Pettersson wrote:
>  > > 
>  > > ftape-4.04? That's been a non-integrated external package for ages and ages.
>  > > I doubt there's been any updates in it for 2.5/2.6 kernels.
>  > >...
>  > 
>  > Is there a good reason why it wasn't / isn't integrated?
> 
> Claus-Justus (the official maintainer) never bothered doing it.

I gave up trying to update the in-kernel ftape version because I my updates 
didn't come through (that was before the 2.2 and again before the 2.4 kernels 
were released). There are more pleasant wastes of time than to try to go 
through a one-man super-maintainer's eye of a needle.

Actually, the in-kernel version of ftape should be replaced or deleted, it is 
damn outdated anyway and buggy.

In principle, there were some attempts to elect a new ftape-maintainer some 
time ago (Roby Basak, if I remember right).

I could provide a kernel patch for 2.4 and 2.6 to update the in-kernel version 
of ftape if that is wanted.

Otherwise I'd suggest to remove me from the maintainer's list and/or delete 
ftape from the kernel source tree.

Greetings

Claus

--
    Dipl.-Math. Claus-Justus Heine
    Institute for Applied Mathematics              Phone: +49-761-203-5647
    Hermann-Herder-Str. 10                         Fax: +49-761-203-5632
    Freiburg University
    79104 Freiburg / Brsg., Germany


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

* Re: time for some drivers to be removed?
  2003-08-06 10:06         ` Claus-Justus Heine
@ 2003-08-09 19:40           ` Adrian Bunk
  0 siblings, 0 replies; 46+ messages in thread
From: Adrian Bunk @ 2003-08-09 19:40 UTC (permalink / raw)
  To: Claus-Justus Heine; +Cc: Mikael Pettersson, heine, alan, linux-kernel

On Wed, Aug 06, 2003 at 12:06:52PM +0200, Claus-Justus Heine wrote:
>...
> I could provide a kernel patch for 2.4 and 2.6 to update the in-kernel 
> version of ftape if that is wanted.
> 
> Otherwise I'd suggest to remove me from the maintainer's list and/or delete 
> ftape from the kernel source tree.

Allthough I'm no user of ftape I do consider it a bad thing that the 
in-kernel version of a driver is that much outdated.

Could you provide a patch against 2.6?

> Greetings
> 
> Claus

TIA
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ 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-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-13 20:55 John Bradford
  2003-08-13 20:50 ` Adrian Bunk
@ 2003-08-13 20:55 ` Bill Davidsen
  1 sibling, 0 replies; 46+ messages in thread
From: Bill Davidsen @ 2003-08-13 20:55 UTC (permalink / raw)
  To: John Bradford; +Cc: bunk, alan, linux-kernel, wowbagger

On Wed, 13 Aug 2003, John Bradford wrote:

> > > > 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'.

I was thinking more of not even compiling with SMP set, not so much
compiling but not working. I think that covers the above cli/sti example,
and perhaps there are still drivers which will work built in, but not
compile as modules due to the module redesign.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.


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

* 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
  1 sibling, 0 replies; 46+ messages in thread
From: Adrian Bunk @ 2003-08-13 20:50 UTC (permalink / raw)
  To: John Bradford; +Cc: davidsen, alan, linux-kernel, wowbagger

On Wed, Aug 13, 2003 at 09:55:29PM +0100, John Bradford wrote:
> > > > 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.

> John.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


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

* Re: time for some drivers to be removed?
  2003-07-29 19:33               ` Adrian Bunk
@ 2003-08-13 20:16                 ` Bill Davidsen
  0 siblings, 0 replies; 46+ messages in thread
From: Bill Davidsen @ 2003-08-13 20:16 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Alan Cox, David D. Hagood, Linux Kernel Mailing List

On Tue, 29 Jul 2003, Adrian Bunk wrote:

> > 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.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.


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

* Re: time for some drivers to be removed?
  2003-08-09 18:04   ` David Woodhouse
@ 2003-08-09 19:36     ` Adrian Bunk
  0 siblings, 0 replies; 46+ messages in thread
From: Adrian Bunk @ 2003-08-09 19:36 UTC (permalink / raw)
  To: David Woodhouse; +Cc: spse, Robert P. J. Day, Linux kernel mailing list

On Sat, Aug 09, 2003 at 07:04:55PM +0100, David Woodhouse wrote:
> On Sun, 2003-07-27 at 16:31, Adrian Bunk wrote:
> 
> > A first patch is at
> >   http://www.ussg.iu.edu/hypermail/linux/kernel/0306.2/0770.html
> > 
> > I'll send an updated patch against -test2 or -test3.
> 
> Please don't make blkmtd depend on CONFIG_BROKEN. Its maintainer sent a
> patch to Linus recently -- further resends seem to be required.

If it will be merged, my CONFIG_BROKEN patch will be merged soon before 
2.6.0 and it seems that's still a few months from now. When I'll resend 
the next version I'll double-check that all BROKEN drivers are still 
broken.

> dwmw2

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


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

* Re: time for some drivers to be removed?
  2003-07-27 15:31 ` Adrian Bunk
  2003-07-27 15:59   ` David D. Hagood
@ 2003-08-09 18:04   ` David Woodhouse
  2003-08-09 19:36     ` Adrian Bunk
  1 sibling, 1 reply; 46+ messages in thread
From: David Woodhouse @ 2003-08-09 18:04 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: spse, Robert P. J. Day, Linux kernel mailing list

On Sun, 2003-07-27 at 16:31, Adrian Bunk wrote:

> A first patch is at
>   http://www.ussg.iu.edu/hypermail/linux/kernel/0306.2/0770.html
> 
> I'll send an updated patch against -test2 or -test3.

Please don't make blkmtd depend on CONFIG_BROKEN. Its maintainer sent a
patch to Linus recently -- further resends seem to be required.

-- 
dwmw2



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

* Re: time for some drivers to be removed?
  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
  1 sibling, 1 reply; 46+ messages in thread
From: Adrian Bunk @ 2003-07-29 19:33 UTC (permalink / raw)
  To: Alan Cox; +Cc: David D. Hagood, Linux Kernel Mailing List

On Sun, Jul 27, 2003 at 09:56:11PM +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 ?

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.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ 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 20:56             ` Alan Cox
@ 2003-07-28  2:23               ` Herbert Pötzl
  2003-07-29 19:33               ` Adrian Bunk
  1 sibling, 0 replies; 46+ messages in thread
From: Herbert Pötzl @ 2003-07-28  2:23 UTC (permalink / raw)
  To: Alan Cox; +Cc: Adrian Bunk, David D. Hagood, Linux Kernel Mailing List

On Sun, Jul 27, 2003 at 09:56:11PM +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 ?

I'm no native speaker, but Webster says:

obsolete:

 a) no longer in use or no longer useful 
 b) of a kind or style no longer current

broken:

 2) damaged or altered by breaking
 5) not complete or full

so I would prefer BROKEN over OBSOLETE, at least
for drivers which are known _not_ to work as expected,
but OBSOLETE over BROKEN for oldfashioned, but working
drivers superceeded by newer ones ...

JMHO,
Herbert

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

* Re: time for some drivers to be removed?
  2003-07-27 20:40         ` Alan Cox
@ 2003-07-27 20:56           ` Adrian Bunk
  2003-07-27 20:56             ` Alan Cox
  0 siblings, 1 reply; 46+ messages in thread
From: Adrian Bunk @ 2003-07-27 20:56 UTC (permalink / raw)
  To: Alan Cox; +Cc: David D. Hagood, Linux Kernel Mailing List

On Sun, Jul 27, 2003 at 09:40:43PM +0100, Alan Cox wrote:
> On Sul, 2003-07-27 at 19:45, David D. Hagood wrote:
> > I would disagree - OBSOLETE to me means just that - that module is 
> > obsolete. Minix FS, OSS (as opposed to ALSA), and the old non-SCSI, 
> > non-IDE HD interfaces would be OBSOLETE.
> > 
> > Besides, I have seen cases where Firewire modules wouldn't build for 
> > some period of time - would you deem them OBSOLETE?
> 
> The code in question is obsolete if it wont build because its out of date
> with respect to the core. The point I was trying to make is we have a
> definition (have had since 2.2) and actively use it. So there is nothing
> to invent here

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?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


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

* Re: time for some drivers to be removed?
  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
  0 siblings, 2 replies; 46+ messages in thread
From: Alan Cox @ 2003-07-27 20:56 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: David D. Hagood, Linux Kernel Mailing List

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 ?

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

* Re: time for some drivers to be removed?
  2003-07-27 18:45       ` David D. Hagood
@ 2003-07-27 20:40         ` Alan Cox
  2003-07-27 20:56           ` Adrian Bunk
  0 siblings, 1 reply; 46+ messages in thread
From: Alan Cox @ 2003-07-27 20:40 UTC (permalink / raw)
  To: David D. Hagood; +Cc: Adrian Bunk, Robert P. J. Day, Linux Kernel Mailing List

On Sul, 2003-07-27 at 19:45, David D. Hagood wrote:
> I would disagree - OBSOLETE to me means just that - that module is 
> obsolete. Minix FS, OSS (as opposed to ALSA), and the old non-SCSI, 
> non-IDE HD interfaces would be OBSOLETE.
> 
> Besides, I have seen cases where Firewire modules wouldn't build for 
> some period of time - would you deem them OBSOLETE?

The code in question is obsolete if it wont build because its out of date
with respect to the core. The point I was trying to make is we have a
definition (have had since 2.2) and actively use it. So there is nothing
to invent here


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

* Re: time for some drivers to be removed?
  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
  1 sibling, 1 reply; 46+ messages in thread
From: David D. Hagood @ 2003-07-27 18:45 UTC (permalink / raw)
  To: Alan Cox; +Cc: Adrian Bunk, Robert P. J. Day, Linux Kernel Mailing List

Alan Cox wrote:
> We've had one for years. Its CONFIG_OBSOLETE, its even used in 2.6test

I would disagree - OBSOLETE to me means just that - that module is 
obsolete. Minix FS, OSS (as opposed to ALSA), and the old non-SCSI, 
non-IDE HD interfaces would be OBSOLETE.

Besides, I have seen cases where Firewire modules wouldn't build for 
some period of time - would you deem them OBSOLETE?


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

* Re: time for some drivers to be removed?
  2003-07-27 16:40     ` Alan Cox
@ 2003-07-27 17:00       ` Adrian Bunk
  2003-07-27 18:45       ` David D. Hagood
  1 sibling, 0 replies; 46+ messages in thread
From: Adrian Bunk @ 2003-07-27 17:00 UTC (permalink / raw)
  To: Alan Cox; +Cc: David D. Hagood, Robert P. J. Day, Linux Kernel Mailing List

On Sun, Jul 27, 2003 at 05:40:18PM +0100, Alan Cox wrote:
> On Sul, 2003-07-27 at 16:59, David D. Hagood wrote:
> > This is a pet peeve of mine on Free Software projects in general - The 
> > Program That Wouldn't Compile.
> > 
> > It would seem to me that in the context of the kernel, what is needed is 
> > a BROKEN flag.
> 
> We've had one for years. Its CONFIG_OBSOLETE, its even used in 2.6test

Disclaimer:
I'm not a native English speaker.

In my ears, "obsolete" sounds like "there's something newer instead" and 
"broken" sounds like "it doesn't work at the moment".

This might be wrong, but if it's right I do prefer BROKEN.

Anyway, it's not that important whether OBSOLETE or BROKEN is used.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


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

* Re: time for some drivers to be removed?
  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
  1 sibling, 2 replies; 46+ messages in thread
From: Alan Cox @ 2003-07-27 16:40 UTC (permalink / raw)
  To: David D. Hagood; +Cc: Adrian Bunk, Robert P. J. Day, Linux Kernel Mailing List

On Sul, 2003-07-27 at 16:59, David D. Hagood wrote:
> This is a pet peeve of mine on Free Software projects in general - The 
> Program That Wouldn't Compile.
> 
> It would seem to me that in the context of the kernel, what is needed is 
> a BROKEN flag.

We've had one for years. Its CONFIG_OBSOLETE, its even used in 2.6test


^ 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-27 15:59   ` David D. Hagood
@ 2003-07-27 16:18     ` Adrian Bunk
  2003-07-27 16:40     ` Alan Cox
  1 sibling, 0 replies; 46+ messages in thread
From: Adrian Bunk @ 2003-07-27 16:18 UTC (permalink / raw)
  To: David D. Hagood; +Cc: Robert P. J. Day, Linux kernel mailing list

On Sun, Jul 27, 2003 at 10:59:39AM -0500, David D. Hagood wrote:
>...
> An item with a BROKEN flag would NOT be built in an ALLYES or ALLMODULE 
> configuration - it would require the user to explicitly enable the item 
> in the configuration, and the user would be notified that the module in 
> question was not compiling/linking the last time the configuration data 
> was updated by the kernel team.
>...

I tend to disagree.

IMHO every selectable configuration should result in a kernel that 
compiles. Yes, it's neaarly impossible to achieve this 100%, but at 
least on i386 we are in 2.4 near to it for all not-very-obscure 
configurations.

Where's the win if you are able to select an option that doesn't 
compile? This will only cause confusion for people who compile more into 
the kernel than needed (but it does no harm).

Don't forget: The vast majorit of people compiling the kernel don't know 
anything about the internals of the kernel.

If you _really_ want to see the cmpile errors it's easy to edit the 
Kconfig file.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


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

* Re: time for some drivers to be removed?
  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-08-09 18:04   ` David Woodhouse
  1 sibling, 2 replies; 46+ messages in thread
From: David D. Hagood @ 2003-07-27 15:59 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Robert P. J. Day, Linux kernel mailing list

This is a pet peeve of mine on Free Software projects in general - The 
Program That Wouldn't Compile.

It would seem to me that in the context of the kernel, what is needed is 
a BROKEN flag.

An item with a BROKEN flag would NOT be built in an ALLYES or ALLMODULE 
configuration - it would require the user to explicitly enable the item 
in the configuration, and the user would be notified that the module in 
question was not compiling/linking the last time the configuration data 
was updated by the kernel team.

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).

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

But that's just my opinion.


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

* Re: 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
  2003-07-27 15:59   ` David D. Hagood
  2003-08-09 18:04   ` David Woodhouse
  1 sibling, 2 replies; 46+ messages in thread
From: Adrian Bunk @ 2003-07-27 15:31 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Linux kernel mailing list

On Thu, Jul 24, 2003 at 08:20:44AM -0400, Robert P. J. Day wrote:
> 
>   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?

A first patch is at
  http://www.ussg.iu.edu/hypermail/linux/kernel/0306.2/0770.html

I'll send an updated patch against -test2 or -test3.

Ideally, these drivers will be fixed during 2.6 when more people start 
using 2.6...

> rday

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ 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 19:07     ` Alan Cox
@ 2003-07-25 10:48       ` Bas Mevissen
  0 siblings, 0 replies; 46+ messages in thread
From: Bas Mevissen @ 2003-07-25 10:48 UTC (permalink / raw)
  To: Alan Cox; +Cc: Linux Kernel Mailing List

Alan Cox wrote:

> The OBSOLETE stuff is already used on a couple of drivers that are obsolete
> since 2.2 (although I fixed two of them as they got fixed in 2.4 in the
> end)
> 

O.K. So if something is marked obsolete, you need to edit some config 
file to make it to (try to) compile again.

Making it a config option doesn't make sense as you are going to edit 
things anyway. (if I assume that obsolete stuff is mostly broken TOO).

Regards,

Bas.



^ 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
  1 sibling, 0 replies; 46+ messages in thread
From: Bas Mevissen @ 2003-07-25 10:48 UTC (permalink / raw)
  To: John Bradford; +Cc: diegocg, rpjday, linux-kernel

John Bradford wrote:
> 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.

Bas.




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

* Re: time for some drivers to be removed?
  2003-07-24 19:16         ` Diego Calleja García
@ 2003-07-24 19:43           ` Robert P. J. Day
  0 siblings, 0 replies; 46+ messages in thread
From: Robert P. J. Day @ 2003-07-24 19:43 UTC (permalink / raw)
  To: Diego Calleja García; +Cc: ml, linux-kernel

On Thu, 24 Jul 2003, Diego Calleja [ISO-8859-15] García wrote:

> El Thu, 24 Jul 2003 13:50:48 -0400 (EDT) "Robert P. J. Day" <rpjday@mindspring.com> escribió:
> 
> > 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.
> 
> well, AFAIK "make allyesconfig" is a debug target; ie. it 
> shouldn't be succesful from a developer point of view.

you're right, that's a good point.  but using the example
i used before, it should still not be acceptable to allow
someone to select the "riscom8" driver explicitly and have 
it fail to compile.

your point about the debug target is well taken, though.

ok, i'm going back to work now.  really.

rday

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

* Re: time for some drivers to be removed?
  2003-07-24 18:31 ` Robert P. J. Day
@ 2003-07-24 19:31   ` Eli Carter
  0 siblings, 0 replies; 46+ messages in thread
From: Eli Carter @ 2003-07-24 19:31 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: John Bradford, diegocg, Linux kernel mailing list, ml

Robert P. J. Day wrote:
> p.s.  and, yes, i think "make allyesconfig" should just plain work
> for official release kernels.  so there. :-P

Why not add "make allworkingconfig"?  Turn on everything that builds; 
and maintain it so it reflects reality.  Post patches regularly. ;)

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------


^ 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, 0 replies; 46+ messages in thread
From: Brian Jackson @ 2003-07-24 19:24 UTC (permalink / raw)
  To: linux-kernel

On Thursday 24 July 2003 09:43 am, John Bradford wrote:
<snip>
>
> 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?

I can think of one reason:
$ ls -lhGrS /usr/portage/distfiles/linux-2.*

-rw-r--r--    1      23M Apr 10  2002 
/usr/portage/distfiles/linux-2.4.18.tar.bz2
-rw-r--r--    1      25M Aug 19  2002 
/usr/portage/distfiles/linux-2.4.19.tar.bz2
-rw-r--r--    1      26M Feb 22 21:26 
/usr/portage/distfiles/linux-2.4.20.tar.bz2
-rw-r--r--    1      27M Jun 13 09:52 
/usr/portage/distfiles/linux-2.4.21.tar.bz2
-rw-r--r--    1      30M Feb 10 13:05 
/usr/portage/distfiles/linux-2.5.60.tar.bz2
-rw-r--r--    1      30M Feb 24 13:30 
/usr/portage/distfiles/linux-2.5.63.tar.bz2
-rw-r--r--    1      30M Mar  4 21:47 
/usr/portage/distfiles/linux-2.5.64.tar.bz2
-rw-r--r--    1      30M Mar 17 16:29 
/usr/portage/distfiles/linux-2.5.65.tar.bz2
-rw-r--r--    1      30M Apr 19 22:02 
/usr/portage/distfiles/linux-2.5.68.tar.bz2
-rw-r--r--    1      30M Mar 24 17:23 
/usr/portage/distfiles/linux-2.5.66.tar.bz2
-rw-r--r--    1      30M Apr 11 12:16 
/usr/portage/distfiles/linux-2.5.67.tar.bz2
-rw-r--r--    1      32M Jul 10 15:21 
/usr/portage/distfiles/linux-2.5.75.tar.bz2

2.6 doesn't seem to be swelling that fast, but 2.4 is

>
> John.

--Brian Jackson

-- 
OpenGFS -- http://opengfs.sourceforge.net
Home -- http://www.brianandsara.net


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

* Re: time for some drivers to be removed?
  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
  0 siblings, 1 reply; 46+ messages in thread
From: Diego Calleja García @ 2003-07-24 19:16 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: ml, linux-kernel

El Thu, 24 Jul 2003 13:50:48 -0400 (EDT) "Robert P. J. Day" <rpjday@mindspring.com> escribió:

> 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.

well, AFAIK "make allyesconfig" is a debug target; ie. it 
shouldn't be succesful from a developer point of view.

I guess what you meant is if we want to say to final users
"the driver for your hardware doesn't compile" or "your hardware isn't
supported (unless you're a developer who wants to fix it)" in which case
i'd say "yes"

Or instead, "should make allyesconfig compile drivers marked as obsolete",
where i'd also say "yes"

But sadly i can't fix all those drivers so i'll stop whining and let the real
developers do whatever they want ;)

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

* Re: time for some drivers to be removed?
  2003-07-24 15:34   ` Bas Mevissen
  2003-07-24 17:32     ` Diego Calleja García
@ 2003-07-24 19:07     ` Alan Cox
  2003-07-25 10:48       ` Bas Mevissen
  1 sibling, 1 reply; 46+ messages in thread
From: Alan Cox @ 2003-07-24 19:07 UTC (permalink / raw)
  To: Bas Mevissen; +Cc: Linux Kernel Mailing List

On Iau, 2003-07-24 at 16:34, Bas Mevissen wrote:
> Is this something for the kernel config? Just below CONFIG_EXPERIMENTEL 
> in the menu, add CONFIG_OBSOLETE. The 'make allyesconfig' and the like 
> can ignore experimental and obsolete stuff.

The OBSOLETE stuff is already used on a couple of drivers that are obsolete
since 2.2 (although I fixed two of them as they got fixed in 2.4 in the
end)



^ 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-24 19:31   ` Eli Carter
  2003-07-25 10:48 ` Bas Mevissen
  1 sibling, 1 reply; 46+ messages in thread
From: Robert P. J. Day @ 2003-07-24 18:31 UTC (permalink / raw)
  To: John Bradford; +Cc: diegocg, Linux kernel mailing list, ml

On Thu, 24 Jul 2003, John Bradford wrote:

> i wrote:

> > 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.

whoa, calm down.  i didn't mean to start that kind of flame war. for the
record, i feel that, if something is *known* to be broken, it should not
be in the source tree.  naturally, in the testing process, there will
be stuff that has bugs, which is why we test.  but i'm just not buying
the argument of leaving modules like riscom8 in the tree for release
after release when it hasn't compiled properly for as long as i can
remember.

but the impression i've gotten so far is that some folks are adamant that
some broken/non-updated/legacy/obsolete/whatever code will remain in the
source tree because it might be fixed *some day*.  if that's the case,
then i think such code should be marked or tagged *somehow* as being
broken.

it's a matter of public perception -- it looks bad to ship code that
is *known* not to compile.

and on that note, i'll let this one go.  my $0.02.  $0.03 canadian.

rday

p.s.  and, yes, i think "make allyesconfig" should just plain work
for official release kernels.  so there. :-P

^ 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 17:32     ` Diego Calleja García
  2003-07-24 17:50       ` Robert P. J. Day
@ 2003-07-24 18:02       ` Samuel Flory
  1 sibling, 0 replies; 46+ messages in thread
From: Samuel Flory @ 2003-07-24 18:02 UTC (permalink / raw)
  To: Diego Calleja García; +Cc: Bas Mevissen, linux-kernel

Diego Calleja García wrote:

>El Thu, 24 Jul 2003 17:34:44 +0200 Bas Mevissen <ml@basmevissen.nl> escribió:
>
>  
>
>>This would make a reasonable Q-requirement for 2.6.0 that at least the 
>>kernel compiles with 'make allyesconfig'. The only thing open is to 
>>    
>>
>
>That 2.6.0 builds with 'make allyesconfig' or not is irrelevant.
>Moving broken drivers to a dark place doesn't fix them  nor increase the
>"quality" level.....
>  
>

  It certainly improves perceived quality level.  People new to linux 
are going to think 2.6 is a pile of crap that will not compile.  Not to 
mention it reduces the possible things that can trip up a new

-- 
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>



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

* Re: time for some drivers to be removed?
  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 18:02       ` Samuel Flory
  1 sibling, 1 reply; 46+ messages in thread
From: Robert P. J. Day @ 2003-07-24 17:50 UTC (permalink / raw)
  To: Diego Calleja García; +Cc: Bas Mevissen, linux-kernel

On Thu, 24 Jul 2003, Diego Calleja [ISO-8859-15] García wrote:

> El Thu, 24 Jul 2003 17:34:44 +0200 Bas Mevissen <ml@basmevissen.nl> escribió:
> 
> > This would make a reasonable Q-requirement for 2.6.0 that at least the 
> > kernel compiles with 'make allyesconfig'. The only thing open is to 
> 
> That 2.6.0 builds with 'make allyesconfig' or not is irrelevant.
> Moving broken drivers to a dark place doesn't fix them  nor increase the
> "quality" level.....

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.

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.

rday

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

* Re: time for some drivers to be removed?
  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 18:02       ` Samuel Flory
  2003-07-24 19:07     ` Alan Cox
  1 sibling, 2 replies; 46+ messages in thread
From: Diego Calleja García @ 2003-07-24 17:32 UTC (permalink / raw)
  To: Bas Mevissen; +Cc: linux-kernel

El Thu, 24 Jul 2003 17:34:44 +0200 Bas Mevissen <ml@basmevissen.nl> escribió:

> This would make a reasonable Q-requirement for 2.6.0 that at least the 
> kernel compiles with 'make allyesconfig'. The only thing open is to 

That 2.6.0 builds with 'make allyesconfig' or not is irrelevant.
Moving broken drivers to a dark place doesn't fix them  nor increase the
"quality" level.....

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

* Re: time for some drivers to be removed?
  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 19:07     ` Alan Cox
  0 siblings, 2 replies; 46+ messages in thread
From: Bas Mevissen @ 2003-07-24 15:34 UTC (permalink / raw)
  To: Alan Cox; +Cc: Linux-kernel

Alan Cox wrote:

> 
> So someone coming from 2.4 can fix it when they need it. You can tag
> such things with && OBSOLETE, we did that in 2.4.
> 

Is this something for the kernel config? Just below CONFIG_EXPERIMENTEL 
in the menu, add CONFIG_OBSOLETE. The 'make allyesconfig' and the like 
can ignore experimental and obsolete stuff.

This would make a reasonable Q-requirement for 2.6.0 that at least the 
kernel compiles with 'make allyesconfig'. The only thing open is to 
decide what is obsolete and what not (and needs fix). That is not 
trivial. IMHO, Linus some time ago had a good statement about it, but it 
is somewhat hard to see how long something is broken from the code alone :-)

If this is a good idea, I'll supply a patch for 2.6.0-something with at 
least some non-compiling stuff marked obsolete.

Regards,

Bas.




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

* Re: 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-24 15:34   ` Bas Mevissen
  2003-07-27 15:31 ` Adrian Bunk
  1 sibling, 1 reply; 46+ messages in thread
From: Alan Cox @ 2003-07-24 14:58 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Linux Kernel Mailing List

On Iau, 2003-07-24 at 13:20, Robert P. J. Day wrote:
>   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?

So someone coming from 2.4 can fix it when they need it. You can tag
such things with && OBSOLETE, we did that in 2.4.


^ 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-05 12:42 time for some drivers to be removed? 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
  -- strict thread matches above, loose matches on Subject: below --
2003-08-14  5:34 John Bradford
2003-08-13 20:55 John Bradford
2003-08-13 20:50 ` Adrian Bunk
2003-08-13 20:55 ` Bill Davidsen
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).