The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Osamu Tomita <tomita@cinet.co.jp>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Dave Jones <davej@codemonkey.org.uk>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHSET 1/25] add support for PC-9800 architecture (apm)
Date: Thu, 24 Oct 2002 00:44:52 +0900	[thread overview]
Message-ID: <3DB6C3F4.4A2C4EC5@cinet.co.jp> (raw)
In-Reply-To: Pine.GSO.4.21.0210231257200.12783-100000@vervain.sonytel.be

Geert Uytterhoeven wrote:
> 
> On Fri, 18 Oct 2002, Dave Jones wrote:
> > On Sat, Oct 19, 2002 at 01:56:19AM +0900, Osamu Tomita wrote:
> >  > This patchset adds support for NEC PC-9800 architecture, against 2.5.43.
> >  > Fixed bad things commented by Russell King.
> >  >
> >  > PC-9800 series machines are made by NEC. But sold only in japan.
> >  > Formaly, they were best sellers in japan.
> >  > We port linux for PC-9800 since 2.1.57.
> >  >
> >  > I'm testing 2.5.43 with this patchset on some boxes.
> >  > - PC-9800 i586 UP with IDE drive
> >  > - PC-9800 i686 SMP with SCSI drive
> >  > - AT compatible with IDE drive (patch applied but not set CONFIG_PC9800).
> >  > They works well.
> >  > We are doing our best, patchset has no effect on original without configuring
> >  > for PC-9800.
> >  > Please apply this patchset.
> >
> > The biggest sticking point as far as I'm concerned with this patchset
> > is the source readability after applying it.
> > Something really needs to be done about the #if pollution this
> > patch adds before it's ready for inclusion. The whole patchset adds
> > over 700 #if's/ifdefs/ifndefs.
> 
> Indeed, I have the same comment after browsing through the frame buffer device
> and console patches.
> 
> I think the need for 32-bit character/attribute data on PC-9800 can easily be
> abstracted inside a few screen specific typedefs, macros, and functions, e.g.
>   - add typedef u32/u16 charattr_t
>   - add scr_kmalloc() to allocate virtual console buffers
>   - modify scr_readw() and friends for character/attribute data access
> and a lot of the #ifdef's can be removed.
> 
> What do you think?
Indeed. I'll try it in next step. Thank you very much.

Regards
Osamu Tomita

      reply	other threads:[~2002-10-23 15:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-18 16:56 [PATCHSET 1/25] add support for PC-9800 architecture (apm) Osamu Tomita
2002-10-18 17:47 ` Dave Jones
2002-10-19  0:47   ` [PATCHSET 1/25] add support for PC-9800 architecture Osamu Tomita
2002-10-23 11:03   ` [PATCHSET 1/25] add support for PC-9800 architecture (apm) Geert Uytterhoeven
2002-10-23 15:44     ` Osamu Tomita [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DB6C3F4.4A2C4EC5@cinet.co.jp \
    --to=tomita@cinet.co.jp \
    --cc=davej@codemonkey.org.uk \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox