pupa-devel
[Top][All Lists]
Advanced

[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





reply via email to

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