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

[Evgeniy Ivanov <lolkaantimat%gmail.com@localhost>]

Hi,

On Sun, Dec 18, 2011 at 7:24 AM, Izumi Tsutsui 
<tsutsui%ceres.dti.ne.jp@localhost> wrote:
> Hi,
>
>> Izumi, thank you for reviewing! New patches are attached.
>  :
>> >> Here is a fix for the issue. Independent on what fs partition
>> >> contains, ufs_ls() was called. Because of ext2 and ufs similarity it
>> >> worked successfully in some cases.
>
> Now I'm told that OpenBSD has introduced "readdir" ops in libsa fs_ops:
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/lib/libsa/readdir.c
>
> And at least OpenBSD/zaurus uses these readdir ops for ls command:
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/zaurus/stand/zboot/cmd.c?rev=1.3

i386 bootloader has it too:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/stand/boot/Attic/cmd.c

> 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.

>> > We also have to check all other non-x86 bootloaders which refer ufs_ls().
>> > (ews4800mips, ia64, landisk, x68k, zaurus etc)
>>
>> Done. I'm not able to check though, but the modification is trivial
>> and almost the same as for i386.
>
> I'll take these tier II ports anyway. Thanks.
>
> ---
> Izumi Tsutsui



-- 
Evgeniy Ivanov