[Top][All Lists]
[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
- PUPA disk questions, Marco Gerards, 2003/10/24
- Re: PUPA disk questions,
Yoshinori K. Okuji <=
- Re: PUPA disk questions, Marco Gerards, 2003/10/25
- Re: PUPA disk questions, Yoshinori K. Okuji, 2003/10/25
- Re: PUPA disk questions, Marco Gerards, 2003/10/25
- Re: PUPA disk questions, Yoshinori K. Okuji, 2003/10/25
- Re: PUPA disk questions, Marco Gerards, 2003/10/26
- Re: PUPA disk questions, Yoshinori K. Okuji, 2003/10/27
Re: PUPA disk questions, Marco Gerards, 2003/10/27