pupa-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PUPA disk questions


From: Yoshinori K. Okuji
Subject: Re: PUPA disk questions
Date: Sat, 25 Oct 2003 13:03:24 +0200
User-agent: KMail/1.5

On Saturday 25 October 2003 00:15, Marco Gerards wrote:
> Hopefully this still the right mailing list for PUPA related
> questions...

No problem.

> The first problem I encountered was while booting from a partition on
> my 27GB hard drive.  I assume the fat partition wasn't accessible
> because it has a high cylinder number.  AFAIK the lba functions should
> be used and I see some lba related code in boot.S.  Do you have some
> ideas how I can debug his problem?  I know how to read and write IA32
> assembly, but I'm no expert so I need some help or directions.

Is your drive accessible with GRUB? The code in PUPA was stolen from GRUB, so 
if GRUB can access it, PUPA should be able to access it, theoretically.

> The second problem is that I couldn't read a fat filesystem from
> floppy because block 0 of the floppy I boot from was loaded into the
> cache.  When I swapped floppies it was still in cache and the new
> floppy wasn't read.  How about a "cache" command that can be used to
> disable caching for all devices or a specific device and flush the
> cache for all devices or a specific device?

Oops, I'm sorry that I forgot to mention this in the file TODO. I wrote some 
information about this in Japanese several months ago, and here is a 
translation:

There remains a problem in disk caches, that it does not care about media 
changes. In GRUB, caches are invalidated whenever waiting for data input, but 
this is not very good, so it is better to ask device drivers at a certain 
timing. It would be easier if we use interrupts, but we decided not to use 
interrupts in GRUB/PUPA, so more consideration is required. If we use the 
GRUB way, when starting waiting for data input (i.e. when calling getkey()), 
it is possible to set a mark somewhere then to check caches when disk 
accesses are coming. However, this is complicated, it might be better to ask 
device drivers each time a disk is opened.

I think it is a good idea to have the command "cache" for debug purpose, but 
the real fix should be:

1. Add an additional function to the framework of disk drivers. It should 
invalidate caches, if and only if required.

or,

2. Add code to check media changes into the "open" function of each disk 
driver.

I guess the second solution is better, but I'm not sure.

> I have been working on ext2fs last week and I have something that
> works perfectly for me.

Great! It looks nice.

BTW, did you try your code on any architecture else i386? I think you have 
written the code carefully, but it would be good to make sure that your code 
is portable with real machines.

> What will normal mode look like?  Will it be like the rescue mode:
> just add all required commands to command.c or will it be really
> modular and will all commands be loaded from disk?  Which commands
> will normal mode have compared to rescue mode?

Ideally, you should not register commands in command.c. Please do this, only 
if this is inevitable (like the psuedo command "title"). I'd like to keep 
PUPA as modular as possible, so that PUPA is flexible enough.

The normal mode should have all commands you want to have. ;)
Basically, it should have the same set of commands as GRUB, but you don't have 
to add unnecessary commands and you may change semantics freely.

Probably this is the most interesting part in PUPA development. It is 
necessary to redesign all GRUB commands. I haven't redesigned everything, but 
this is a basic strategy:

* Make all commands consistent. They should look like GNU commands. For 
example, all commands should support long options, and short options 
optionally.

* Get rid of magic, like the command "install" in GRUB. Instead, extend other 
intelligent commands, such as "setup".

* Don't guess the type of a kernel any longer. This was just complex. Instead, 
prepare one command for one kernel type. For example, "linux" for Linux, 
"netbsd" for NetBSD.

Also, it is necessary to make the interface powerful enough, like GRUB. The 
rescue mode is quite dumb, and it is ok. The normal mode should support 
useful features seen in readline. Unlike GRUB, I'd like to make the interface 
customizable somehow. For example, some people prefer vi-like key bindings.

Of course, the normal mode should have a menu interface as well. I have 
already added it, but the current implementation is only for a presentation, 
so it is welcome to change the look-and-feel completely, if desirable.

Marco, if you have good ideas, don't hesitate! PUPA is a very good chance to 
change GRUB radically.

Regards,
Okuji




reply via email to

[Prev in Thread] Current Thread [Next in Thread]