Re: I write a patch for Japanese NEC i386 old computers.

[Yoshinori K. Okuji]

On Wednesday 28 March 2007 17:27, Hitoshi Ozeki wrote:
> 1. name of architecture.
>
> In Japan, The 'PC-98' means the NEC PC-9800 series and its compatible
> machines.
> But, In the other country, 'PC98' means a hardware standard set by
> Microsoft and
> a consortium of hardware manufacturers.
> I afraid to mistake, so named as 'NEC98'. But, I do not have a intent to
> persist this name.

It is very difficult to say what name is appropriate. As far as I know, there 
is no consensus about this. FreeBSD uses "pc98", but I guess this is only 
because 386BSD(98) used "pc98", which was probably named by Ishii-san or 
Kojima-san.

Uhmm, very difficult. You are right, PC98 might be a bit confusing for some 
people. But NEC98 is unusual to me, and it sounds like excluding Epson's 
models.

For now, I prefer "pc98", because it is at least consistent with FreeBSD.

> 2. sharing of code with PC's.
>
> Sharing of code with PC's bring me several problems.
> Firstly, In this time, My patch includes a lot of PC's code. But amount of
> the PC-9800 depended code will increase.

Good point. If you think it is hard to share code, please don't try to share 
too much. Something I really want to avoid is to use a lot of cpp 
conditionals, only to share code.

> Secondaly, when changes PC's depended code, PC-9800 code shuld change also.
> I think GRUB2 is next generation
> of GRUB, not on the stable.

Yes, but I don't think it will change radically. I would like to change the 
way of reserving memory for GRUB, but this change should not affect so much.

> 4. Wish to discuss.
>
> * Support of different sector-sizes, MO(Magneto Optical) disk uses
> 512/1024/2048 b/s(bytes per sector).
>   CD-ROM uses 2048 b/s, FD of formatted by PC-9800 series often uses 1024
> b/s, Old OS uses 256/128 b/s.

I think there are two different ways to address this issue. One way is to use  
variable sector size. This looks elegant, but this affects the disk device 
API very much. The other is to use fixed sector size, as it is for now, but 
align boundaries at a device driver level. The latter way is used for GRUB 
Legacy to support CDROM, and it works well.

I don't know which way is better. What do you think?

> * When doing 'chainloader' command, the all disk devices cannot use via
> 'dev.c',
>   because of doing 'grub_loader_unload_func'  on 'grub_loader_set'.
>   I think it is disirable to do 'grub_loader_unload_func' on 'grub_*_boot'.

Could you elaborate on why this is bad?

Okuji