[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PUPA disk questions
From: |
Marco Gerards |
Subject: |
Re: PUPA disk questions |
Date: |
25 Oct 2003 16:03:56 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
"Yoshinori K. Okuji" <address@hidden> writes:
> On Saturday 25 October 2003 14:16, Marco Gerards wrote:
> > GRUB works perfectly, but PUPA doesn't. If you have no idea where I
> > should look I have to debug all this.
>
> Sorry, I have no idea. To investigate this problem, I'd recommend looking at
> disk/i386/pc/biosdisk.c. The code is mostly the same as stage2/bios.c in
> GRUB.
Ok.
> > > 2. Add code to check media changes into the "open" function of each disk
> > > driver.
> >
> > I think it makes sense but we need to be sure all architectures can
> > detect such change. Otherwise we need to invalidate the cache for a
> > device when it is opened (or better, when it is closed).
>
> I think it is okay. If you don't like invalidating caches all the time, you
> could define a minimum life time of caches (e.g. one second), as nobody can
> exchange a media so quickly.
I agree. This requires a timer and possibly interrupts, is that a
problem?
> > I've tested my ext2fs code on another box yesterday and it didn't
> > compile because of the way I've used the union. This was on gcc 2.95
> > (IIRC) but it works perfectly on gcc 3.0 (and newer). What is the
> > goal of PUPA? Does it have to work on all compilers and should it
> > work on every POSIX system?
>
> Could you elaborate on how you used union?
...
pupa_uint32_t flags;
pupa_uint32_t osd1;
union
{
struct datablocks
{
pupa_uint32_t dir_blocks[INDIRECT_BLOCKS];
pupa_uint32_t indir_block;
pupa_uint32_t double_indir_block;
pupa_uint32_t tripple_indir_block;
};
char symlink[60];
};
pupa_uint32_t version;
pupa_uint32_t acl;
...
Perhaps this just sucks, I didn't have my C book nearby. I think it
isn't quite portable, but a lot easier to use. I will have a look if
it is C99 or something like that.
> I think it is generally a good thing to make software portable. So if you
> have
> no specific reason, it is better to make PUPA usable with any version of a C
> compiler.
>
> However, you can use GNU extensions as you want. GRUB is GNU Software, and
> GCC
> and other build tools are quite portable, so I don't care about non-GNU build
> tools.
I love the GNU extensions and personally I don't care about other compilers.
> > > * Get rid of magic, like the command "install" in GRUB. Instead, extend
> > > other intelligent commands, such as "setup".
> >
> > How will setup work? Will it be interactive? IIRC install was really
> > confusing.
>
> I'd like to hear your idea. I myself don't see why an interactive setup
> command could be useful.
I didn't have any idea yet, I'd appreciate your opinion here. I was
just wondering if what you had in mind was an interactive setup.
> > Will it be possible to have multiple user interfaces? For example a
> > mouse controlled gui or an alternative menu. I would like some
> > modularity here so it is possible to add some "user friendly" GUIs.
> > AFAIK some non-free bootloaders have that so I think it would be nice
> > if PUPA has such features too. Of course this is long term thinking.
>
> Yes, it is nice.
>
> Do you know there are two different interfaces even in GRUB? Recent versions
> of GRUB use horizontal scrolls for long lines, while older versions used line
> folding in one screen. This change was to support dumb terminals. For a dumb
> terminal, readline also does the same thing.
I didn't know this, thanks.
[...]
BTW, ext2fs works on the PPC. I had to make a few small changes. (I
forgot a few pupa_le_to_cpuxx calls.
Thanks,
Marco
Re: PUPA disk questions, Marco Gerards, 2003/10/27