LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: [patch] kill off PC9800
@ 2004-05-16 17:50 James Bottomley
  2004-05-16 21:21 ` Andrew Morton
  0 siblings, 1 reply; 21+ messages in thread
From: James Bottomley @ 2004-05-16 17:50 UTC (permalink / raw)
  To: Andrew Morton, randy.dunlap; +Cc: Linux Kernel

    Randy.Dunlap" <rddunlap@osdl.org> wrote:
    >
    >  PC9800 sub-arch is incomplete, hackish (at least in IDE), maintainers
    >  don't reply to emails and haven't touched it in awhile.
    
    And the hardware is obsolete, isn't it?  Does anyone know when they were
    last manufactured, and how popular they are?
    
Hey, just being obsolete is no grounds for eliminating a
subarchitecture...

However, I would have to say that being unmaintained is.  Because of the
penchant of x86 people to go "it compiles on my PC, ship it", the x86
subarchitectures are about the fastest bitrotting pieces of the kernel
there are.

Since mach-pc9800 cannot currently be compiled and there's no evidence
that it actually was, I'd remove it unless someone steps up quickly to
maintain it (and get it to the point where it's actually compileable).

James



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

* Re: [patch] kill off PC9800
  2004-05-16 17:50 [patch] kill off PC9800 James Bottomley
@ 2004-05-16 21:21 ` Andrew Morton
  2004-05-16 21:28   ` Jeff Garzik
  2004-05-18 20:14   ` Matt Mackall
  0 siblings, 2 replies; 21+ messages in thread
From: Andrew Morton @ 2004-05-16 21:21 UTC (permalink / raw)
  To: James Bottomley; +Cc: linux-kernel, Randy.Dunlap

James Bottomley <James.Bottomley@SteelEye.com> wrote:
>
>     Randy.Dunlap" <rddunlap@osdl.org> wrote:
>     >
>     >  PC9800 sub-arch is incomplete, hackish (at least in IDE), maintainers
>     >  don't reply to emails and haven't touched it in awhile.
>     
>     And the hardware is obsolete, isn't it?  Does anyone know when they were
>     last manufactured, and how popular they are?
>     
> Hey, just being obsolete is no grounds for eliminating a
> subarchitecture...

Well it's a question of whether we're likely to see increasing demand for
it in the future.  If so then it would be prudent to put some effort into
fixing it up rather than removing it.

Seems that's not the case.  I don't see a huge rush on this but if after
this discussion nobody steps up to take care of the code over the next few
weeks, it's best to remove it.

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

* Re: [patch] kill off PC9800
  2004-05-16 21:21 ` Andrew Morton
@ 2004-05-16 21:28   ` Jeff Garzik
  2004-05-16 21:38     ` James Bottomley
  2004-05-18 20:14   ` Matt Mackall
  1 sibling, 1 reply; 21+ messages in thread
From: Jeff Garzik @ 2004-05-16 21:28 UTC (permalink / raw)
  To: Andrew Morton; +Cc: James Bottomley, linux-kernel, Randy.Dunlap

Andrew Morton wrote:
> Well it's a question of whether we're likely to see increasing demand for
> [pc9800] in the future.  If so then it would be prudent to put some effort into
> fixing it up rather than removing it.
> 
> Seems that's not the case.  I don't see a huge rush on this but if after
> this discussion nobody steps up to take care of the code over the next few
> weeks, it's best to remove it.


Although I like deleting things as much as the next guy :) I do have a 
question, to which I haven't come up with a good answer myself:

Should PC9800 be excised en masse, or just toss the obviously broken or 
not-in-any-makefile/Kconfig pieces?

The PC9800 net driver stuff still seems to build, and be sane.

	Jeff




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

* Re: [patch] kill off PC9800
  2004-05-16 21:28   ` Jeff Garzik
@ 2004-05-16 21:38     ` James Bottomley
  2004-05-17 17:15       ` Jeff Garzik
  0 siblings, 1 reply; 21+ messages in thread
From: James Bottomley @ 2004-05-16 21:38 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: Andrew Morton, Linux Kernel, Randy.Dunlap

On Sun, 2004-05-16 at 16:28, Jeff Garzik wrote:
> Although I like deleting things as much as the next guy :) I do have a 
> question, to which I haven't come up with a good answer myself:
> 
> Should PC9800 be excised en masse, or just toss the obviously broken or 
> not-in-any-makefile/Kconfig pieces?
> 
> The PC9800 net driver stuff still seems to build, and be sane.

I haven't looked at the net stuff but if it's like the SCSI stuff, it's
only usable in a pc9800.  The vanilla kernel currently has no way to
select a pc9800 subarchitecture build.

This is a test of interest.  Since the pc9800 can't build the vanilla
kernel, is anyone maintaining the out of tree pieces to allow it to
build, and would they take on the job of maintaining it in-tree? if
no-one's interested in maintaining the pc9800 subarchitecture
components, it stands to reason that no-one is going to be compiling or
running the net or scsi drivers, so there's no point keeping them
hanging around.  Thus, if one piece goes, they all should.

James



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

* Re: [patch] kill off PC9800
  2004-05-16 21:38     ` James Bottomley
@ 2004-05-17 17:15       ` Jeff Garzik
  0 siblings, 0 replies; 21+ messages in thread
From: Jeff Garzik @ 2004-05-17 17:15 UTC (permalink / raw)
  To: James Bottomley; +Cc: Andrew Morton, Linux Kernel, Randy.Dunlap

James Bottomley wrote:
> On Sun, 2004-05-16 at 16:28, Jeff Garzik wrote:
> 
>>Although I like deleting things as much as the next guy :) I do have a 
>>question, to which I haven't come up with a good answer myself:
>>
>>Should PC9800 be excised en masse, or just toss the obviously broken or 
>>not-in-any-makefile/Kconfig pieces?
>>
>>The PC9800 net driver stuff still seems to build, and be sane.
> 
> 
> I haven't looked at the net stuff but if it's like the SCSI stuff, it's
> only usable in a pc9800.  The vanilla kernel currently has no way to
> select a pc9800 subarchitecture build.
> 
> This is a test of interest.  Since the pc9800 can't build the vanilla
> kernel, is anyone maintaining the out of tree pieces to allow it to
> build, and would they take on the job of maintaining it in-tree? if
> no-one's interested in maintaining the pc9800 subarchitecture
> components, it stands to reason that no-one is going to be compiling or
> running the net or scsi drivers, so there's no point keeping them
> hanging around.  Thus, if one piece goes, they all should.


Yeah, I suppose I agree, though I dislike removing it en masse for some 
reason.  No real technical reason, more just gut feeling...  The PC9800 
people spent a good long while working with Alan and others to get what 
little bits got merged into the kernel.

I suppose disappearing and not maintaining the code is the overriding 
factor here...

	Jeff




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

* Re: [patch] kill off PC9800
  2004-05-16 21:21 ` Andrew Morton
  2004-05-16 21:28   ` Jeff Garzik
@ 2004-05-18 20:14   ` Matt Mackall
  2004-05-18 20:23     ` Brian Gerst
  1 sibling, 1 reply; 21+ messages in thread
From: Matt Mackall @ 2004-05-18 20:14 UTC (permalink / raw)
  To: Andrew Morton; +Cc: James Bottomley, linux-kernel, Randy.Dunlap

On Sun, May 16, 2004 at 02:21:23PM -0700, Andrew Morton wrote:
> James Bottomley <James.Bottomley@SteelEye.com> wrote:
> >
> >     Randy.Dunlap" <rddunlap@osdl.org> wrote:
> >     >
> >     >  PC9800 sub-arch is incomplete, hackish (at least in IDE), maintainers
> >     >  don't reply to emails and haven't touched it in awhile.
> >     
> >     And the hardware is obsolete, isn't it?  Does anyone know when they were
> >     last manufactured, and how popular they are?
> >     
> > Hey, just being obsolete is no grounds for eliminating a
> > subarchitecture...
> 
> Well it's a question of whether we're likely to see increasing demand for
> it in the future.  If so then it would be prudent to put some effort into
> fixing it up rather than removing it.
> 
> Seems that's not the case.  I don't see a huge rush on this but if after
> this discussion nobody steps up to take care of the code over the next few
> weeks, it's best to remove it.

Perhaps a nicer way to do this is to add a compile warning or error:

#warning "arch/i386/mach-pc9800 unmaintained since xx/xx/xx, nominated
for removal xx/xx/xx if unclaimed"

..where the second date is, say, 3+ months after the warning goes in.
Then people can nominate stuff for removal with one liners and users
will get ample opportunity to complain.

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

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

* Re: [patch] kill off PC9800
  2004-05-18 20:14   ` Matt Mackall
@ 2004-05-18 20:23     ` Brian Gerst
  2004-05-18 20:53       ` Matt Mackall
  0 siblings, 1 reply; 21+ messages in thread
From: Brian Gerst @ 2004-05-18 20:23 UTC (permalink / raw)
  To: Matt Mackall; +Cc: Andrew Morton, James Bottomley, linux-kernel, Randy.Dunlap

Matt Mackall wrote:

> On Sun, May 16, 2004 at 02:21:23PM -0700, Andrew Morton wrote:
> 
>>James Bottomley <James.Bottomley@SteelEye.com> wrote:
>>
>>>    Randy.Dunlap" <rddunlap@osdl.org> wrote:
>>>    >
>>>    >  PC9800 sub-arch is incomplete, hackish (at least in IDE), maintainers
>>>    >  don't reply to emails and haven't touched it in awhile.
>>>    
>>>    And the hardware is obsolete, isn't it?  Does anyone know when they were
>>>    last manufactured, and how popular they are?
>>>    
>>>Hey, just being obsolete is no grounds for eliminating a
>>>subarchitecture...
>>
>>Well it's a question of whether we're likely to see increasing demand for
>>it in the future.  If so then it would be prudent to put some effort into
>>fixing it up rather than removing it.
>>
>>Seems that's not the case.  I don't see a huge rush on this but if after
>>this discussion nobody steps up to take care of the code over the next few
>>weeks, it's best to remove it.
> 
> 
> Perhaps a nicer way to do this is to add a compile warning or error:
> 
> #warning "arch/i386/mach-pc9800 unmaintained since xx/xx/xx, nominated
> for removal xx/xx/xx if unclaimed"
> 
> ..where the second date is, say, 3+ months after the warning goes in.
> Then people can nominate stuff for removal with one liners and users
> will get ample opportunity to complain.
> 

You're missing the point that this code doesn't compile *at all*. 
Nobody would ever see the warning.

--
				Brian Gerst

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

* Re: [patch] kill off PC9800
  2004-05-18 20:23     ` Brian Gerst
@ 2004-05-18 20:53       ` Matt Mackall
  2004-05-18 21:14         ` James Bottomley
  0 siblings, 1 reply; 21+ messages in thread
From: Matt Mackall @ 2004-05-18 20:53 UTC (permalink / raw)
  To: Brian Gerst; +Cc: Andrew Morton, James Bottomley, linux-kernel, Randy.Dunlap

On Tue, May 18, 2004 at 04:23:18PM -0400, Brian Gerst wrote:
> Matt Mackall wrote:
> 
> >On Sun, May 16, 2004 at 02:21:23PM -0700, Andrew Morton wrote:
> >
> >>James Bottomley <James.Bottomley@SteelEye.com> wrote:
> >>
> >>>   Randy.Dunlap" <rddunlap@osdl.org> wrote:
> >>>   >
> >>>   >  PC9800 sub-arch is incomplete, hackish (at least in IDE), 
> >>>   maintainers
> >>>   >  don't reply to emails and haven't touched it in awhile.
> >>>   
> >>>   And the hardware is obsolete, isn't it?  Does anyone know when they 
> >>>   were
> >>>   last manufactured, and how popular they are?
> >>>   
> >>>Hey, just being obsolete is no grounds for eliminating a
> >>>subarchitecture...
> >>
> >>Well it's a question of whether we're likely to see increasing demand for
> >>it in the future.  If so then it would be prudent to put some effort into
> >>fixing it up rather than removing it.
> >>
> >>Seems that's not the case.  I don't see a huge rush on this but if after
> >>this discussion nobody steps up to take care of the code over the next few
> >>weeks, it's best to remove it.
> >
> >
> >Perhaps a nicer way to do this is to add a compile warning or error:
> >
> >#warning "arch/i386/mach-pc9800 unmaintained since xx/xx/xx, nominated
> >for removal xx/xx/xx if unclaimed"
> >
> >..where the second date is, say, 3+ months after the warning goes in.
> >Then people can nominate stuff for removal with one liners and users
> >will get ample opportunity to complain.
> >
> 
> You're missing the point that this code doesn't compile *at all*. 
> Nobody would ever see the warning.

Actually it's a matter of fail to attempt to compile, which is
different than fail to compile. The principle is the same - stick
advance notice in a highly visible place where users are likely to see
it. That place is _not_ this mailing list.

We've had the code for years, and it would be nice to delete it if
it's truly dead. But it seems silly to wake up one morning and say "no
one's touched it for a year" and post a patch to delete it that same
day. If it wasn't urgent yesterday, then why is it urgent today?

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

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

* Re: [patch] kill off PC9800
  2004-05-18 20:53       ` Matt Mackall
@ 2004-05-18 21:14         ` James Bottomley
  0 siblings, 0 replies; 21+ messages in thread
From: James Bottomley @ 2004-05-18 21:14 UTC (permalink / raw)
  To: Matt Mackall; +Cc: Brian Gerst, Andrew Morton, Linux Kernel, Randy.Dunlap

On Tue, 2004-05-18 at 15:53, Matt Mackall wrote:
> Actually it's a matter of fail to attempt to compile, which is
> different than fail to compile. The principle is the same - stick
> advance notice in a highly visible place where users are likely to see
> it. That place is _not_ this mailing list.
> 
> We've had the code for years, and it would be nice to delete it if
> it's truly dead. But it seems silly to wake up one morning and say "no
> one's touched it for a year" and post a patch to delete it that same
> day. If it wasn't urgent yesterday, then why is it urgent today?

I would agree if it were a complete feature, but it's not.  PC9800
cannot be selected for compilation in the current kernel.  Without an
external patch set, it cannot be compiled or used.  As far as I can
tell, it's always been like that.

I think the best way of making someone sit up and take notice is simply
to remove it.  After all, given that we have the kernel under source
control it's not like it's going to be hard to put it back if someone
actually does notice and screams...

James



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

* Re: [patch] kill off PC9800
  2004-05-17 21:59       ` Norman Diamond
  2004-05-17 22:33         ` Bartlomiej Zolnierkiewicz
@ 2004-05-18  1:04         ` viro
  1 sibling, 0 replies; 21+ messages in thread
From: viro @ 2004-05-18  1:04 UTC (permalink / raw)
  To: Norman Diamond; +Cc: Roland Dreier, Adrian Bunk, linux-kernel

On Tue, May 18, 2004 at 06:59:49AM +0900, Norman Diamond wrote:
 
> Do you realize that Apple's market share is still less than NEC's?  And if
> you want to go back 10 years, NEC had about 90% of the PC market and they
> were all 9800 series.

So are you volunteering to maintain the port?  Maintainers are MIA; the
damn thing doesn't compile; all patches it gets are basically blind
ones ("we have that API change, this ought to take care of those drivers
and let's hope that possible mistakes will be caught by testers").
Considering the lack of testers (kinda hard to test something that
refuses to build), the above actually spells in one word: "bitrot".

Either somebody shows up and takes over the damn thing, or it's just a
dead weight that could as well be left in linux-2.6.6.tar.bz2 on
kernel.org and not propagated any further.  If at some later point
somebody will decide to resurrected, they can always pick it from
said tarball.

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

* Re: [patch] kill off PC9800
  2004-05-17 21:59       ` Norman Diamond
@ 2004-05-17 22:33         ` Bartlomiej Zolnierkiewicz
  2004-05-18  1:04         ` viro
  1 sibling, 0 replies; 21+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2004-05-17 22:33 UTC (permalink / raw)
  To: Norman Diamond, Roland Dreier; +Cc: Adrian Bunk, linux-kernel


Just to get back on topic...

We want to kill PC9800 port because it is a dead code
(unfinished and unmaintained) but developers still have
to waste time on updating it while making some unrelated
changes.

It has nothing to do with not liking PC9800 hardware
or thinking that it is obsolete.

PPC port in contrary to PC9800 one has very active developers.

On Monday 17 of May 2004 23:59, Norman Diamond wrote:
> Roland Dreier replied to me:
> >     Norman> I'll bet that the number of PC9800 machines still in
> >     Norman> existence is an order of magnitude larger than the number
> >     Norman> of PowerPC machines still in existence (including current
> >     Norman> ones).
> >
> > Do you realize that every Apple Macintosh sold for about the last 10
> > years is PowerPC-based?
>
> Do you realize that Apple's market share is still less than NEC's?  And if
> you want to go back 10 years, NEC had about 90% of the PC market and they
> were all 9800 series.
>
> > Not to mention all of IBM's midrange-servers
> > (p and i series).  Plus a huge embedded presense.
>
> OK, NEC's servers are not PCs.  (Or at least they didn't used to be.)  But
> their numbers hardly affect PC statistics.


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

* Re: [patch] kill off PC9800
  2004-05-17 21:51     ` Roland Dreier
  2004-05-17 21:59       ` Norman Diamond
@ 2004-05-17 22:17       ` Joel Jaeggli
  1 sibling, 0 replies; 21+ messages in thread
From: Joel Jaeggli @ 2004-05-17 22:17 UTC (permalink / raw)
  To: Roland Dreier; +Cc: Norman Diamond, Adrian Bunk, linux-kernel

On 17 May 2004, Roland Dreier wrote:
> 
> I don't know how many PC9800 machines were made but I can't believe
> it's that many.

then you've never been to japan.

but I think this got off track.

The salient issues as I understand them are:

pc9800 has been broken for a while. 

There is currently no maintainer.

it's not likely to become unbroken anytime soon.

the principle stakeholders would seem to be people with pc9800 machines 
who run linux which means input from the linux/98 project if it's still 
extant but baring that it's just a pile of dead code.

Looking back through my mail I see Alan Cox touched it sometime in the 
2.5.66 era.
 
>  - Roland
> -
> 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/
> 

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli  	       Unix Consulting 	       joelja@darkwing.uoregon.edu    
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2



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

* Re: [patch] kill off PC9800
  2004-05-17 21:51     ` Roland Dreier
@ 2004-05-17 21:59       ` Norman Diamond
  2004-05-17 22:33         ` Bartlomiej Zolnierkiewicz
  2004-05-18  1:04         ` viro
  2004-05-17 22:17       ` Joel Jaeggli
  1 sibling, 2 replies; 21+ messages in thread
From: Norman Diamond @ 2004-05-17 21:59 UTC (permalink / raw)
  To: Roland Dreier; +Cc: Adrian Bunk, linux-kernel

Roland Dreier replied to me:

>     Norman> I'll bet that the number of PC9800 machines still in
>     Norman> existence is an order of magnitude larger than the number
>     Norman> of PowerPC machines still in existence (including current
>     Norman> ones).
>
> Do you realize that every Apple Macintosh sold for about the last 10
> years is PowerPC-based?

Do you realize that Apple's market share is still less than NEC's?  And if
you want to go back 10 years, NEC had about 90% of the PC market and they
were all 9800 series.

> Not to mention all of IBM's midrange-servers
> (p and i series).  Plus a huge embedded presense.

OK, NEC's servers are not PCs.  (Or at least they didn't used to be.)  But
their numbers hardly affect PC statistics.


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

* Re: [patch] kill off PC9800
  2004-05-17 21:38   ` Norman Diamond
@ 2004-05-17 21:51     ` Roland Dreier
  2004-05-17 21:59       ` Norman Diamond
  2004-05-17 22:17       ` Joel Jaeggli
  0 siblings, 2 replies; 21+ messages in thread
From: Roland Dreier @ 2004-05-17 21:51 UTC (permalink / raw)
  To: Norman Diamond; +Cc: Adrian Bunk, linux-kernel

    Norman> I'll bet that the number of PC9800 machines still in
    Norman> existence is an order of magnitude larger than the number
    Norman> of PowerPC machines still in existence (including current
    Norman> ones).

Do you realize that every Apple Macintosh sold for about the last 10
years is PowerPC-based?  Not to mention all of IBM's midrange-servers
(p and i series).  Plus a huge embedded presense.

I don't know how many PC9800 machines were made but I can't believe
it's that many.

 - Roland

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

* Re: [patch] kill off PC9800
  2004-05-16 16:36 ` Adrian Bunk
@ 2004-05-17 21:38   ` Norman Diamond
  2004-05-17 21:51     ` Roland Dreier
  0 siblings, 1 reply; 21+ messages in thread
From: Norman Diamond @ 2004-05-17 21:38 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: linux-kernel

Adrian Bunk replied to me:

> > When were PowerPC, MIPS (other than embedded), and Alpha chips last
> > manufactured, and how popular are they?
>
> All of them are still manufactored.

Oh, then there is no comparison.  I had not seen any in the marketplace in
recent years and just assumed they were no longer being made.

> With at about 3 million computers and notebooks sold with a preinstalled
> Unix in 2003, PowerPC is definitely one of the most popular Unix
> platforms today.

OK, but I'll bet the preinstalled Unix isn't Linux.  You don't say how many
owners switched to Linux, so as a WAG let's say 10%.  Let's also WAG that
10% of PC9800 owners switched from preinstalled Monopoly Windows to X11
Windows plus Linux.  I'll bet that the number of PC9800 machines still in
existence is an order of magnitude larger than the number of PowerPC
machines still in existence (including current ones).

This still doesn't mean that I like the PC9800 by the way.  For comparison,
Monopolysoft taught me to hate Monopolysoft, but for some reason I think it
would not be wise to delete FAT and NTFS filesystem handlers from Linux.


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

* Re: [patch] kill off PC9800
  2004-05-16 16:16   ` GOTO Masanori
@ 2004-05-16 17:25     ` Randy.Dunlap
  0 siblings, 0 replies; 21+ messages in thread
From: Randy.Dunlap @ 2004-05-16 17:25 UTC (permalink / raw)
  To: GOTO Masanori; +Cc: akpm, linux-kernel, B.Zolnierkiewicz

On Mon, 17 May 2004 01:16:13 +0900 GOTO Masanori <gotom@debian.or.jp> wrote:

| At Sat, 15 May 2004 23:28:58 -0700,
| Andrew Morton wrote:
| > "Randy.Dunlap" <rddunlap@osdl.org> wrote:
| > >
| > >  PC9800 sub-arch is incomplete, hackish (at least in IDE), maintainers
| > >  don't reply to emails and haven't touched it in awhile.
| > 
| > And the hardware is obsolete, isn't it?  Does anyone know when they were
| > last manufactured, and how popular they are?
| 
| Well NEC PC9800 serires were stopped to manufacture a few years
| before.  But even so, it seems there're users to use this type of
| hardware.  There were one Japanese distribution which supported
| PC9800.  So I wonder it should be really needed to remove.

Well, it's just not usable at all in its current from in the
maintained Linux tree, so if it's used by someone, it requires
lots of other patches (approx. 136 KB patch), which should be
submitted for review/evaluation and possible merging.

It needs to be fixed and maintained (which is not a one-time thing,
but a continuing job), or it should go away, and people who might
use it can use an even larger out-of-kernel-tree patch.

--
~Randy

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

* Re: [patch] kill off PC9800
  2004-05-16  7:35 Norman Diamond
@ 2004-05-16 16:36 ` Adrian Bunk
  2004-05-17 21:38   ` Norman Diamond
  0 siblings, 1 reply; 21+ messages in thread
From: Adrian Bunk @ 2004-05-16 16:36 UTC (permalink / raw)
  To: Norman Diamond; +Cc: linux-kernel

On Sun, May 16, 2004 at 04:35:19PM +0900, Norman Diamond wrote:
>...
> When were PowerPC, MIPS (other than embedded), and Alpha chips last
> manufactured, and how popular are they?
>...

All of them are still manufactored.

Each of these three architectures has more than one machine manufactured
2003 listed as one of the 500 fastest computers in the world (place 2
and 3 are Alpha and PowerPC machines that are faster than the fastest
i386 and ia64 machines in the world) [1].

SGI still sells many MIPS-based computers running IRIX.

With at about 3 million computers and notebooks sold with a preinstalled
Unix in 2003, PowerPC is definitely one of the most popular Unix
platforms today.

cu
Adrian

[1] http://www.top500.org

-- 

       "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] 21+ messages in thread

* Re: [patch] kill off PC9800
  2004-05-16  6:28 ` Andrew Morton
@ 2004-05-16 16:16   ` GOTO Masanori
  2004-05-16 17:25     ` Randy.Dunlap
  0 siblings, 1 reply; 21+ messages in thread
From: GOTO Masanori @ 2004-05-16 16:16 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Randy.Dunlap, linux-kernel, B.Zolnierkiewicz

At Sat, 15 May 2004 23:28:58 -0700,
Andrew Morton wrote:
> "Randy.Dunlap" <rddunlap@osdl.org> wrote:
> >
> >  PC9800 sub-arch is incomplete, hackish (at least in IDE), maintainers
> >  don't reply to emails and haven't touched it in awhile.
> 
> And the hardware is obsolete, isn't it?  Does anyone know when they were
> last manufactured, and how popular they are?

Well NEC PC9800 serires were stopped to manufacture a few years
before.  But even so, it seems there're users to use this type of
hardware.  There were one Japanese distribution which supported
PC9800.  So I wonder it should be really needed to remove.

Regards,
-- gotom


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

* Re: [patch] kill off PC9800
@ 2004-05-16  7:35 Norman Diamond
  2004-05-16 16:36 ` Adrian Bunk
  0 siblings, 1 reply; 21+ messages in thread
From: Norman Diamond @ 2004-05-16  7:35 UTC (permalink / raw)
  To: linux-kernel

Andrew Morton wrote:
> "Randy.Dunlap" <rddunlap@osdl.org> wrote:
> >
> >  PC9800 sub-arch is incomplete, hackish (at least in IDE), maintainers
> >  don't reply to emails and haven't touched it in awhile.
>
> And the hardware is obsolete, isn't it?  Does anyone know when they were
> last manufactured, and how popular they are?

Of course they aren't popular any more, but the last ones were still
respectably powerful and can run stuff like Windows 2000 Server.

When were PowerPC, MIPS (other than embedded), and Alpha chips last
manufactured, and how popular are they?

[By the way the above commendts do not reflect my personal opinion.  A few
years ago a friend got one free.  It wasn't one of the last and repectably
powerful ones, it had a 486 and 10MB of RAM.  It was amazingly hard to get
Windows 95 installed onto it, because I had no experience with the
architecture (other than having read a few things such as hard disk
partitions being DOS letters A, B, and then presumably E and upwards, and it
turned out that this wasn't true when booting from a floppy, and the PC98
version of Windows 95 confused itself too when doing its normal reboots from
the hard disk part way through installation...).  After being installed,
Windows 95 ran impressively well in 10MB of RAM.  The GUI responded to mouse
clicks immediately, none of the sluggishness normally associated with X11
Windows and XP Windows.  Even opening a document in WordPad came up without
waiting.  However, the installation process was so painful that I told my
friend my opinion of his computer.  Even when he got it free, it was worth
less than he paid for it.]


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

* Re: [patch] kill off PC9800
  2004-05-16  6:21 Randy.Dunlap
@ 2004-05-16  6:28 ` Andrew Morton
  2004-05-16 16:16   ` GOTO Masanori
  0 siblings, 1 reply; 21+ messages in thread
From: Andrew Morton @ 2004-05-16  6:28 UTC (permalink / raw)
  To: Randy.Dunlap; +Cc: linux-kernel, B.Zolnierkiewicz

"Randy.Dunlap" <rddunlap@osdl.org> wrote:
>
>  PC9800 sub-arch is incomplete, hackish (at least in IDE), maintainers
>  don't reply to emails and haven't touched it in awhile.

And the hardware is obsolete, isn't it?  Does anyone know when they were
last manufactured, and how popular they are?

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

* [patch] kill off PC9800
@ 2004-05-16  6:21 Randy.Dunlap
  2004-05-16  6:28 ` Andrew Morton
  0 siblings, 1 reply; 21+ messages in thread
From: Randy.Dunlap @ 2004-05-16  6:21 UTC (permalink / raw)
  To: akpm, lkml; +Cc: Bart

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]


PC9800 sub-arch is incomplete, hackish (at least in IDE), maintainers
don't reply to emails and haven't touched it in awhile.
Can't even config it to try to build it without other patches
to the kernel tree.


full diff-style patch: [374 KB]
http://developer.osdl.org/rddunlap/patches/rm-pc9800.diff

bk-rm-script for complete files:  [also attached]
http://developer.osdl.org/rddunlap/patches/pc9800-kill.sh

Difference in first and second (for changes only, not including
'rm' of complete files):  [also attached]
http://developer.osdl.org/rddunlap/patches/rm-pc9800-bits.diff

Comments/feedback?

--
~Randy



[-- Attachment #2: pc9800-kill.sh --]
[-- Type: application/x-sh, Size: 781 bytes --]

[-- Attachment #3: rm-pc9800-bits.diff --]
[-- Type: application/octet-stream, Size: 19123 bytes --]


 drivers/block/Kconfig          |    9 -------
 drivers/char/Kconfig           |   22 -----------------
 drivers/char/Makefile          |    1 
 drivers/ide/Kconfig            |   20 ---------------
 drivers/ide/Makefile           |    1 
 drivers/input/keyboard/Kconfig |   12 ---------
 drivers/input/misc/Kconfig     |    4 ---
 drivers/input/mouse/Kconfig    |   11 --------
 drivers/input/mouse/Makefile   |    1 
 drivers/input/serio/Kconfig    |   10 -------
 drivers/net/Kconfig            |   52 -----------------------------------------
 drivers/net/Makefile           |    1 
 drivers/scsi/Kconfig           |   12 ---------
 drivers/scsi/Makefile          |    2 -
 drivers/serial/Kconfig         |   13 ----------
 drivers/serial/Makefile        |    1 
 fs/partitions/Kconfig          |    7 -----
 fs/partitions/check.c          |    1 
 sound/isa/Kconfig              |   10 -------
 sound/isa/cs423x/Makefile      |    2 -
 20 files changed, 4 insertions(+), 188 deletions(-)


diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/block/Kconfig linux-266-bk1-pc98rm/drivers/block/Kconfig
--- linux-266-bk1/drivers/block/Kconfig	2004-05-09 19:32:26.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/block/Kconfig	2004-05-15 22:31:07.000000000 -0700
@@ -6,7 +6,7 @@ menu "Block devices"
 
 config BLK_DEV_FD
 	tristate "Normal floppy disk support"
-	depends on (!X86_PC9800 && !ARCH_S390 && !M68K && !IA64) || Q40 || (SUN3X && BROKEN)
+	depends on (!ARCH_S390 && !M68K && !IA64) || Q40 || (SUN3X && BROKEN)
 	---help---
 	  If you want to use the floppy disk drive(s) of your PC under Linux,
 	  say Y. Information about this driver, especially important for IBM
@@ -26,13 +26,6 @@ config ATARI_FLOPPY
 	tristate "Atari floppy support"
 	depends on ATARI
 
-config BLK_DEV_FD98
-	tristate "NEC PC-9800 floppy disk support"
-	depends on X86_PC9800
-	---help---
-	  If you want to use the floppy disk drive(s) of NEC PC-9801/PC-9821,
-	  say Y.
-
 config BLK_DEV_SWIM_IOP
 	bool "Macintosh IIfx/Quadra 900/Quadra 950 floppy support (EXPERIMENTAL)"
 	depends on MAC && EXPERIMENTAL && BROKEN
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/char/Kconfig linux-266-bk1-pc98rm/drivers/char/Kconfig
--- linux-266-bk1/drivers/char/Kconfig	2004-05-14 16:43:36.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/char/Kconfig	2004-05-15 22:35:29.000000000 -0700
@@ -586,17 +586,6 @@ config HVC_CONSOLE
 	  console. This driver allows each pSeries partition to have a console
 	  which is accessed via the HMC.
 
-config PC9800_OLDLP
-	tristate "NEC PC-9800 old-style printer port support"
-	depends on X86_PC9800 && !PARPORT
-	---help---
-	  If you intend to attach a printer to the parallel port of NEC PC-9801
-	  /PC-9821 with OLD compatibility mode, Say Y.
-
-config PC9800_OLDLP_CONSOLE
-	bool "Support for console on line printer"
-	depends on PC9800_OLDLP
-
 config QIC02_TAPE
 	tristate "QIC-02 tape support"
 	help
@@ -740,7 +729,7 @@ config NVRAM
 
 config RTC
 	tristate "Enhanced Real Time Clock Support"
-	depends on !PPC32 && !PARISC && !IA64 && !X86_PC9800 && !M68K
+	depends on !PPC32 && !PARISC && !IA64 && !M68K
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
@@ -793,15 +782,6 @@ config EFI_RTC
 	bool "EFI Real Time Clock Services"
 	depends on IA64
 
-config RTC98
-	tristate "NEC PC-9800 Real Time Clock Support"
-	depends on X86_PC9800
-	default y
-	---help---
-	  If you say Y here and create a character special file /dev/rtc with
-	  major number 10 and minor number 135 using mknod ("man mknod"), you
-	  will get access to the real time clock (or hardware clock) built
-
 config H8
 	bool "Tadpole ANA H8 Support (OBSOLETE)"
 	depends on OBSOLETE && ALPHA_BOOK1
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/char/Makefile linux-266-bk1-pc98rm/drivers/char/Makefile
--- linux-266-bk1/drivers/char/Makefile	2004-05-14 16:43:36.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/char/Makefile	2004-05-15 22:34:57.000000000 -0700
@@ -48,7 +48,6 @@ obj-$(CONFIG_VIOTAPE)		+= viotape.o
 
 obj-$(CONFIG_PRINTER) += lp.o
 obj-$(CONFIG_TIPAR) += tipar.o
-obj-$(CONFIG_PC9800_OLDLP) += lp_old98.o
 
 obj-$(CONFIG_DTLK) += dtlk.o
 obj-$(CONFIG_R3964) += n_r3964.o
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/ide/Kconfig linux-266-bk1-pc98rm/drivers/ide/Kconfig
--- linux-266-bk1/drivers/ide/Kconfig	2004-05-09 19:32:29.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/ide/Kconfig	2004-05-15 22:38:09.000000000 -0700
@@ -97,25 +97,7 @@ comment "Please see Documentation/ide.tx
 
 config BLK_DEV_HD_IDE
 	bool "Use old disk-only driver on primary interface"
-	depends on ((X86 && X86_PC9800!=y) || SH_MPC1211)
-	---help---
-	  There are two drivers for MFM/RLL/IDE disks.  Most people use just
-	  the new enhanced driver by itself.  This option however installs the
-	  old hard disk driver to control the primary IDE/disk interface in
-	  the system, leaving the new enhanced IDE driver to take care of only
-	  the 2nd/3rd/4th IDE interfaces.  Doing this will prevent you from
-	  having an IDE/ATAPI CD-ROM or tape drive connected to the primary
-	  IDE interface.  Choosing this option may be useful for older systems
-	  which have MFM/RLL/ESDI controller+drives at the primary port
-	  address (0x1f0), along with IDE drives at the secondary/3rd/4th port
-	  addresses.
-
-	  Normally, just say N here; you will then use the new driver for all
-	  4 interfaces.
-
-config BLK_DEV_HD_IDE98
-	bool "Use old disk-only driver on primary interface"
-	depends on X86 && X86_PC9800
+	depends on (X86 || SH_MPC1211)
 	---help---
 	  There are two drivers for MFM/RLL/IDE disks.  Most people use just
 	  the new enhanced driver by itself.  This option however installs the
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/ide/Makefile linux-266-bk1-pc98rm/drivers/ide/Makefile
--- linux-266-bk1/drivers/ide/Makefile	2004-05-09 19:32:37.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/ide/Makefile	2004-05-15 22:38:47.000000000 -0700
@@ -26,7 +26,6 @@ ide-core-$(CONFIG_PROC_FS)		+= ide-proc.
 ide-core-$(CONFIG_BLK_DEV_IDEPNP)	+= ide-pnp.o
 
 # built-in only drivers from legacy/
-ide-core-$(CONFIG_BLK_DEV_IDE_PC9800)	+= legacy/pc9800.o
 ide-core-$(CONFIG_BLK_DEV_BUDDHA)	+= legacy/buddha.o
 ide-core-$(CONFIG_BLK_DEV_FALCON_IDE)	+= legacy/falconide.o
 ide-core-$(CONFIG_BLK_DEV_GAYLE)	+= legacy/gayle.o
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/input/keyboard/Kconfig linux-266-bk1-pc98rm/drivers/input/keyboard/Kconfig
--- linux-266-bk1/drivers/input/keyboard/Kconfig	2004-05-09 19:33:20.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/input/keyboard/Kconfig	2004-05-15 22:24:25.000000000 -0700
@@ -96,15 +96,3 @@ config KEYBOARD_AMIGA
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called amikbd.
-
-config KEYBOARD_98KBD
-	tristate "NEC PC-9800 Keyboard support"
-	depends on X86_PC9800 && INPUT && INPUT_KEYBOARD
-	select SERIO
-	help
-	  Say Y here if you want to use the NEC PC-9801/PC-9821 keyboard (or
-	  compatible) on your system. 
-
-	  To compile this driver as a module, choose M here: the
-	  module will be called 98kbd.
-
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/input/misc/Kconfig linux-266-bk1-pc98rm/drivers/input/misc/Kconfig
--- linux-266-bk1/drivers/input/misc/Kconfig	2004-05-14 16:43:36.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/input/misc/Kconfig	2004-05-15 22:25:04.000000000 -0700
@@ -40,10 +40,6 @@ config INPUT_M68K_BEEP
 	tristate "M68k Beeper support"
 	depends on M68K && INPUT && INPUT_MISC
 
-config INPUT_98SPKR
-	tristate "PC-9800 Speaker support"
-	depends on X86_PC9800 && INPUT && INPUT_MISC
-
 config INPUT_UINPUT
 	tristate "User level driver support"
 	depends on INPUT && INPUT_MISC
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/input/mouse/Kconfig linux-266-bk1-pc98rm/drivers/input/mouse/Kconfig
--- linux-266-bk1/drivers/input/mouse/Kconfig	2004-05-09 19:33:13.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/input/mouse/Kconfig	2004-05-15 22:25:29.000000000 -0700
@@ -130,14 +130,3 @@ config MOUSE_VSXXXAA
 	  described in the source file). This driver should, in theory,
 	  also work with the digitizer DEC produced, but it isn't tested
 	  with that (I don't have the hardware yet).
-
-config MOUSE_PC9800
-	tristate "NEC PC-9800 busmouse"
-	depends on X86_PC9800 && INPUT && INPUT_MOUSE && ISA
-	help
-	  Say Y here if you have NEC PC-9801/PC-9821 computer and want its
-	  native mouse supported.
-
-	  To compile this driver as a module, choose M here: the
-	  module will be called 98busmouse.
-
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/input/mouse/Makefile linux-266-bk1-pc98rm/drivers/input/mouse/Makefile
--- linux-266-bk1/drivers/input/mouse/Makefile	2004-05-09 19:32:21.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/input/mouse/Makefile	2004-05-15 22:23:57.000000000 -0700
@@ -10,7 +10,6 @@ obj-$(CONFIG_MOUSE_INPORT)	+= inport.o
 obj-$(CONFIG_MOUSE_LOGIBM)	+= logibm.o
 obj-$(CONFIG_MOUSE_MAPLE)	+= maplemouse.o
 obj-$(CONFIG_MOUSE_PC110PAD)	+= pc110pad.o
-obj-$(CONFIG_MOUSE_PC9800)	+= 98busmouse.o
 obj-$(CONFIG_MOUSE_PS2)		+= psmouse.o
 obj-$(CONFIG_MOUSE_SERIAL)	+= sermouse.o
 obj-$(CONFIG_MOUSE_VSXXXAA)	+= vsxxxaa.o
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/input/serio/Kconfig linux-266-bk1-pc98rm/drivers/input/serio/Kconfig
--- linux-266-bk1/drivers/input/serio/Kconfig	2004-05-09 19:32:37.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/input/serio/Kconfig	2004-05-15 22:24:43.000000000 -0700
@@ -97,16 +97,6 @@ config SERIO_SA1111
 	tristate "Intel SA1111 keyboard controller"
 	depends on SA1111 && SERIO
 
-config SERIO_98KBD
-	tristate "NEC PC-9800 keyboard controller"
-	depends on X86_PC9800 && SERIO
-	help
-	  Say Y here if you have the NEC PC-9801/PC-9821 and want to use its
-	  standard keyboard connected to its keyboard controller.
-
-	  To compile this driver as a module, choose M here: the
-	  module will be called 98kbd-io.
-
 config SERIO_GSCPS2
 	tristate "HP GSC PS/2 keyboard and PS/2 mouse controller"
 	depends on GSC && SERIO
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/net/Kconfig linux-266-bk1-pc98rm/drivers/net/Kconfig
--- linux-266-bk1/drivers/net/Kconfig	2004-05-09 19:33:13.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/net/Kconfig	2004-05-15 22:27:19.000000000 -0700
@@ -922,7 +922,7 @@ config HP100
 
 config NET_ISA
 	bool "Other ISA cards"
-	depends on NET_ETHERNET && ISA && !X86_PC9800
+	depends on NET_ETHERNET && ISA
 	---help---
 	  If your network (Ethernet) card hasn't been mentioned yet and its
 	  bus system (that's the way the cards talks to the other components
@@ -1105,56 +1105,6 @@ config SK_G16
 	  the Ethernet-HOWTO, available from
 	  <http://www.tldp.org/docs.html#howto>.
 
-config NET_CBUS
-	bool "NEC PC-9800 C-bus cards"
-	depends on NET_ETHERNET && ISA && X86_PC9800
-	---help---
-	  If your network (Ethernet) card hasn't been mentioned yet and its
-	  bus system (that's the way the cards talks to the other components
-	  of your computer) is NEC PC-9800 C-Bus, say Y.
-
-config NE2K_CBUS
-	tristate "Most NE2000-based Ethernet support"
-	depends on NET_CBUS
-	select CRC32
-
-config NE2K_CBUS_EGY98
-	bool "Melco EGY-98 support"
-	depends on NE2K_CBUS
-
-config NE2K_CBUS_LGY98
-	bool "Melco LGY-98 support"
-	depends on NE2K_CBUS
-
-config NE2K_CBUS_ICM
-	bool "ICM IF-27xxET support"
-	depends on NE2K_CBUS
-
-config NE2K_CBUS_IOLA98
-	bool "I-O DATA LA-98 support"
-	depends on NE2K_CBUS
-
-config NE2K_CBUS_CNET98EL
-	bool "Contec C-NET(98)E/L support"
-	depends on NE2K_CBUS
-
-config NE2K_CBUS_CNET98EL_IO_BASE
-	hex "C-NET(98)E/L I/O base address (0xaaed or 0x55ed)"
-	depends on NE2K_CBUS_CNET98EL
-	default "0xaaed"
-
-config NE2K_CBUS_ATLA98
-	bool "Allied Telesis LA-98 Support"
-	depends on NE2K_CBUS
-
-config NE2K_CBUS_BDN
-	bool "ELECOM Laneed LD-BDN[123]A Support"
-	depends on NE2K_CBUS
-
-config NE2K_CBUS_NEC108
-	bool "NEC PC-9801-108 Support"
-	depends on NE2K_CBUS
-
 config SKMC
 	tristate "SKnet MCA support"
 	depends on NET_ETHERNET && MCA && BROKEN
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/net/Makefile linux-266-bk1-pc98rm/drivers/net/Makefile
--- linux-266-bk1/drivers/net/Makefile	2004-05-09 19:32:26.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/net/Makefile	2004-05-15 22:27:48.000000000 -0700
@@ -81,7 +81,6 @@ obj-$(CONFIG_ARM_ETHERH) += 8390.o
 obj-$(CONFIG_WD80x3) += wd.o 8390.o
 obj-$(CONFIG_EL2) += 3c503.o 8390.o
 obj-$(CONFIG_NE2000) += ne.o 8390.o
-obj-$(CONFIG_NE2K_CBUS) += ne2k_cbus.o 8390.o
 obj-$(CONFIG_NE2_MCA) += ne2.o 8390.o
 obj-$(CONFIG_HPLAN) += hp.o 8390.o
 obj-$(CONFIG_HPLAN_PLUS) += hp-plus.o 8390.o
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/scsi/Kconfig linux-266-bk1-pc98rm/drivers/scsi/Kconfig
--- linux-266-bk1/drivers/scsi/Kconfig	2004-05-14 16:43:36.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/scsi/Kconfig	2004-05-15 22:33:12.000000000 -0700
@@ -1721,18 +1721,6 @@ config SCSI_SUNESP
 	  To compile this driver as a module, choose M here: the
 	  module will be called esp.
 
-config SCSI_PC980155
-	tristate "NEC PC-9801-55 SCSI support"
-	depends on X86_PC9800 && SCSI
-	help
-	  If you have the NEC PC-9801-55 SCSI interface card or compatibles
-	  for NEC PC-9801/PC-9821, say Y.
-
-config WD33C93_PIO
-	bool
-	depends on SCSI_PC980155
-	default y
-
 #      bool 'Cyberstorm Mk III SCSI support (EXPERIMENTAL)' CONFIG_CYBERSTORMIII_SCSI
 
 config ZFCP
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/scsi/Makefile linux-266-bk1-pc98rm/drivers/scsi/Makefile
--- linux-266-bk1/drivers/scsi/Makefile	2004-05-14 16:43:36.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/scsi/Makefile	2004-05-15 22:32:45.000000000 -0700
@@ -34,7 +34,6 @@ obj-$(CONFIG_SCSI_AMIGA7XX)	+= amiga7xx.
 obj-$(CONFIG_A3000_SCSI)	+= a3000.o	wd33c93.o
 obj-$(CONFIG_A2091_SCSI)	+= a2091.o	wd33c93.o
 obj-$(CONFIG_GVP11_SCSI)	+= gvp11.o	wd33c93.o
-obj-$(CONFIG_SCSI_PC980155)	+= pc980155.o	wd33c93.o
 obj-$(CONFIG_MVME147_SCSI)	+= mvme147.o	wd33c93.o
 obj-$(CONFIG_SGIWD93_SCSI)	+= sgiwd93.o	wd33c93.o
 obj-$(CONFIG_CYBERSTORM_SCSI)	+= NCR53C9x.o	cyberstorm.o
@@ -142,7 +141,6 @@ scsi_mod-y			+= scsi.o hosts.o scsi_ioct
 				   scsi_devinfo.o
 scsi_mod-$(CONFIG_SYSCTL)	+= scsi_sysctl.o
 scsi_mod-$(CONFIG_SCSI_PROC_FS)	+= scsi_proc.o
-scsi_mod-$(CONFIG_X86_PC9800)	+= scsi_pc98.o
 
 sd_mod-objs	:= sd.o
 sr_mod-objs	:= sr.o sr_ioctl.o sr_vendor.o
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/serial/Kconfig linux-266-bk1-pc98rm/drivers/serial/Kconfig
--- linux-266-bk1/drivers/serial/Kconfig	2004-05-09 19:33:19.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/serial/Kconfig	2004-05-15 22:29:29.000000000 -0700
@@ -517,19 +517,6 @@ config V850E_UART_CONSOLE
 	depends on V850E_UART
 	select SERIAL_CORE_CONSOLE
 
-config SERIAL98
-	tristate "PC-9800 8251-based primary serial port support"
-	depends on X86_PC9800
-	select SERIAL_CORE
-	help
-	  If you want to use standard primary serial ports on PC-9800, 
-	  say Y.  Otherwise, say N.
-
-config SERIAL98_CONSOLE
-        bool "Support for console on PC-9800 standard serial port"
-        depends on SERIAL98=y
-	select SERIAL_CORE_CONSOLE
-
 config SERIAL_SH_SCI
 	tristate "SH SCI(F) serial port support"
 	depends on SUPERH || H8300
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/drivers/serial/Makefile linux-266-bk1-pc98rm/drivers/serial/Makefile
--- linux-266-bk1/drivers/serial/Makefile	2004-05-09 19:32:36.000000000 -0700
+++ linux-266-bk1-pc98rm/drivers/serial/Makefile	2004-05-15 22:29:34.000000000 -0700
@@ -33,7 +33,6 @@ obj-$(CONFIG_SERIAL_68328) += 68328seria
 obj-$(CONFIG_SERIAL_68360) += 68360serial.o
 obj-$(CONFIG_SERIAL_COLDFIRE) += mcfserial.o
 obj-$(CONFIG_V850E_UART) += v850e_uart.o
-obj-$(CONFIG_SERIAL98) += serial98.o
 obj-$(CONFIG_SERIAL_PMACZILOG) += pmac_zilog.o
 obj-$(CONFIG_SERIAL_AU1X00) += au1x00_uart.o
 obj-$(CONFIG_SERIAL_DZ) += dz.o
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/fs/partitions/check.c linux-266-bk1-pc98rm/fs/partitions/check.c
--- linux-266-bk1/fs/partitions/check.c	2004-05-09 19:33:19.000000000 -0700
+++ linux-266-bk1-pc98rm/fs/partitions/check.c	2004-05-15 22:12:23.000000000 -0700
@@ -29,7 +29,6 @@
 #include "ldm.h"
 #include "mac.h"
 #include "msdos.h"
-#include "nec98.h"
 #include "osf.h"
 #include "sgi.h"
 #include "sun.h"
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/fs/partitions/Kconfig linux-266-bk1-pc98rm/fs/partitions/Kconfig
--- linux-266-bk1/fs/partitions/Kconfig	2004-05-09 19:33:19.000000000 -0700
+++ linux-266-bk1-pc98rm/fs/partitions/Kconfig	2004-05-15 22:08:07.000000000 -0700
@@ -187,13 +187,6 @@ config LDM_DEBUG
 
 	  If unsure, say N.
 
-config NEC98_PARTITION
-	bool "NEC PC-9800 partition table support" if PARTITION_ADVANCED
-	default y if !PARTITION_ADVANCED && X86_PC9800
-	help
-	  Say Y here if you would like to be able to read the hard disk
-	  partition table format used by NEC PC-9800 machines.
-
 config SGI_PARTITION
 	bool "SGI partition support" if PARTITION_ADVANCED
 	default y if !PARTITION_ADVANCED && (SGI_IP22 || SGI_IP27)
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/sound/isa/cs423x/Makefile linux-266-bk1-pc98rm/sound/isa/cs423x/Makefile
--- linux-266-bk1/sound/isa/cs423x/Makefile	2004-05-09 19:33:13.000000000 -0700
+++ linux-266-bk1-pc98rm/sound/isa/cs423x/Makefile	2004-05-15 22:02:39.000000000 -0700
@@ -8,7 +8,6 @@ snd-cs4236-lib-objs := cs4236_lib.o
 snd-cs4231-objs := cs4231.o
 snd-cs4232-objs := cs4232.o
 snd-cs4236-objs := cs4236.o
-snd-pc98-cs4232-objs := pc98.o
 
 # Toplevel Module Dependency
 obj-$(CONFIG_SND_AZT2320) += snd-cs4231-lib.o
@@ -22,6 +21,5 @@ obj-$(CONFIG_SND_INTERWAVE_STB) += snd-c
 obj-$(CONFIG_SND_OPTI92X_CS4231) += snd-cs4231-lib.o
 obj-$(CONFIG_SND_WAVEFRONT) += snd-cs4231-lib.o
 obj-$(CONFIG_SND_SSCAPE) += snd-cs4231-lib.o
-obj-$(CONFIG_SND_PC98_CS4232) += snd-pc98-cs4232.o snd-cs4231-lib.o
 
 obj-m := $(sort $(obj-m))
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl linux-266-bk1/sound/isa/Kconfig linux-266-bk1-pc98rm/sound/isa/Kconfig
--- linux-266-bk1/sound/isa/Kconfig	2004-05-09 19:33:13.000000000 -0700
+++ linux-266-bk1-pc98rm/sound/isa/Kconfig	2004-05-15 22:03:20.000000000 -0700
@@ -51,16 +51,6 @@ config SND_CS4236
 	  Say 'Y' or 'M' to include support for CS4235,CS4236,CS4237B,CS4238B,CS4239
 	  chips from Cirrus Logic - Crystal Semiconductors.
 
-config SND_PC98_CS4232
-	tristate "NEC PC9800 CS4232 driver"
-	depends on SND && X86_PC9800
-	select SND_OPL3_LIB
-	select SND_MPU401_UART
-	select SND_PCM
-	help
-	  Say 'Y' or 'M' to include support for NEC PC-9801/PC-9821 on-board
-	  soundchip based on CS4232.
-
 config SND_ES968
 	tristate "Generic ESS ES968 driver"
 	depends on SND && ISAPNP

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

end of thread, other threads:[~2004-05-18 21:14 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-16 17:50 [patch] kill off PC9800 James Bottomley
2004-05-16 21:21 ` Andrew Morton
2004-05-16 21:28   ` Jeff Garzik
2004-05-16 21:38     ` James Bottomley
2004-05-17 17:15       ` Jeff Garzik
2004-05-18 20:14   ` Matt Mackall
2004-05-18 20:23     ` Brian Gerst
2004-05-18 20:53       ` Matt Mackall
2004-05-18 21:14         ` James Bottomley
  -- strict thread matches above, loose matches on Subject: below --
2004-05-16  7:35 Norman Diamond
2004-05-16 16:36 ` Adrian Bunk
2004-05-17 21:38   ` Norman Diamond
2004-05-17 21:51     ` Roland Dreier
2004-05-17 21:59       ` Norman Diamond
2004-05-17 22:33         ` Bartlomiej Zolnierkiewicz
2004-05-18  1:04         ` viro
2004-05-17 22:17       ` Joel Jaeggli
2004-05-16  6:21 Randy.Dunlap
2004-05-16  6:28 ` Andrew Morton
2004-05-16 16:16   ` GOTO Masanori
2004-05-16 17:25     ` Randy.Dunlap

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