Re: Second stage bootloader (i386) hangs on ls command for ext2

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

Hi,

Evgeniy Ivanov wrote:

> > I have not checked if their readdir() API can be applicable our
> > current ls implementation, but what do you think about this idea,
> > i.e. file system independent ls command using fs dependent readdir() ops?
> >
> > readdir looks better as fs_ops, but if it requires too much
> > modification in our current implementation, ls in fs_ops
> > could be a interim workaround.
> 
> I don't like having ls in fs_ops either and I agree, that readdir
> similar to the OpenBSD's one would be better.
> Ideally, libsa (at least fs_ops) shouldn't produce any output, it's up
> to boot loader to printf.
> 
> The difference is in two parts: fs dependent part should work with an
> external buffer (OpenBSD way, they copy name and then do stat) or
> return a dirent pointer into internal buffer (to have the output they
> get, calling stat() is required, but to keep our current ls output it
> might be skipped). The second is printing the data. Ls should use
> readdir(), but If we leave it in libsa::ls() we will not have any
> benefits from readdir(). And moving it to the bootloaders is not a
> very easy task, because there're plenty of them (and no way to test
> changes for non-i386 arch).
> 
> I think we could leave current approach as interim workaround.

Ok, I agree current OpenBSD's libsa readdir implementation
(without opendir/seekdir/closedir) is incomplete to bother
to integrate only for ls ops.

I'll integrate your patch this weekend unless
someone provides better alternative implementation.
---
Izumi Tsutsui