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
> 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.
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.
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.
El Thu, 24 Jul 2003 17:34:44 +0200 Bas Mevissen <[email protected]> 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.....
On Thu, 24 Jul 2003, Diego Calleja [ISO-8859-15] Garc?a wrote:
> El Thu, 24 Jul 2003 17:34:44 +0200 Bas Mevissen <[email protected]> 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
Diego Calleja Garc?a wrote:
>El Thu, 24 Jul 2003 17:34:44 +0200 Bas Mevissen <[email protected]> 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 <[email protected]>
> 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.
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
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)
El Thu, 24 Jul 2003 13:50:48 -0400 (EDT) "Robert P. J. Day" <[email protected]> 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 ;)
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
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 `-------------------------------------------------
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" <[email protected]> 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
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.
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.
> > 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.
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
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.
> 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.
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
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
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
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?
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
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 ?
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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*.)
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
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
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
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.
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
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.
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..
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
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
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
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
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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> > > 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.
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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> > > > > 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.