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

2011-12-17 Thread Evgeniy Ivanov
Hello,

Izumi, thank you for reviewing! New patches are attached.

On Fri, Dec 16, 2011 at 7:42 PM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:
 Evgeniy Ivanov wrote:

 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.

 netbsd_boot2_ls_fix.diff
     Fix ls command used in second stage bootloader.
  :
 Could someone please review and commit it?

 Looks good, but one concern.

 --- a/sys/arch/i386/stand/bootxx/Makefile.bootxx
 +++ b/sys/arch/i386/stand/bootxx/Makefile.bootxx
 @@ -87,7 +87,8 @@ CPPFLAGS+= -DLIBSA_SINGLE_FILESYSTEM=xxfs \
              -Dblkdevioctl(x,y,z)=EINVAL \
              -Dblkdevclose(f)=0 \
              -Ddevopen(f,n,fl)=(*(fl)=(void *)n,0) \
 -            -DLIBSA_NO_DISKLABEL_MSGS
 +            -DLIBSA_NO_DISKLABEL_MSGS \
 +            -DLIBSA_NO_LS_OP
  :

 --- a/sys/arch/i386/stand/libsa/nfs.c
 +++ b/sys/arch/i386/stand/libsa/nfs.c
  :
 +__compactcall void
 +nfs_ls(struct open_file *f, const char *pattern)
 +{
 +#if !defined(LIBSA_NO_LS_OP)
 +    printf(Currently ls command is unsupported by nfs\n);
 +#endif
 +    return;
 +}

 I think it's better to use a positive LIBSA_ENABLE_LS_OP option rather
 than LIBSA_NO_LS_OP, and make whole (fs_ops)-ls op part optional because
  - there are many primary bootloaders (bootxx_foo) which don't need
   the ls op and have size restrictions (alpha, atari, pmax ...)
  - there are few bootloaders which support command prompt mode where
   the `ls' op is actually required (some ports don't have even getchar())

Done.

 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.



-- 
Evgeniy Ivanov
From 9925d5065fb5de1e495ff0617887ab41f2ac3d31 Mon Sep 17 00:00:00 2001
From: Evgeniy Ivanov lolkaanti...@gmail.com
Date: Tue, 13 Dec 2011 00:23:32 +0400
Subject: [PATCH 1/3] Fix ls command used in second stage bootloader.

Currently only ufs_ls is supported. But if ls is called on ext2
partition, it hangs bootloader, because ufs_ls() is called.
ls command should always call fs-dependent XXX_ls().

diff --git a/sys/arch/i386/stand/boot/Makefile.boot b/sys/arch/i386/stand/boot/Makefile.boot
index feab35f..fc7c5a8 100644
--- a/sys/arch/i386/stand/boot/Makefile.boot
+++ b/sys/arch/i386/stand/boot/Makefile.boot
@@ -76,6 +76,7 @@ CPPFLAGS+= -DPASS_MEMMAP
 CPPFLAGS+= -DEPIA_HACK
 #CPPFLAGS+= -DDEBUG_MEMSIZE
 #CPPFLAGS+= -DBOOT_MSG_COM0
+CPPFLAGS+= -DLIBSA_ENABLE_LS_OP
 
 # The biosboot code is linked to 'virtual' address of zero and is
 # loaded at physical address 0x1.
@@ -113,6 +114,7 @@ LIBI386= ${I386LIB}
 ### find out what to use for libsa
 SA_AS= library
 SAMISCMAKEFLAGS+=SA_USE_LOADFILE=yes
+SAMISCMAKEFLAGS+=SA_ENABLE_LS_OP=yes
 .include ${S}/lib/libsa/Makefile.inc
 LIBSA= ${SALIB}
 
diff --git a/sys/arch/i386/stand/boot/boot2.c b/sys/arch/i386/stand/boot/boot2.c
index 587990e..dc50808 100644
--- a/sys/arch/i386/stand/boot/boot2.c
+++ b/sys/arch/i386/stand/boot/boot2.c
@@ -409,7 +409,7 @@ command_ls(char *arg)
 	const char *save = default_filename;
 
 	default_filename = /;
-	ufs_ls(arg);
+	ls(arg);
 	default_filename = save;
 }
 
diff --git a/sys/arch/i386/stand/dosboot/Makefile b/sys/arch/i386/stand/dosboot/Makefile
index 6ae3b40..165971a 100644
--- a/sys/arch/i386/stand/dosboot/Makefile
+++ b/sys/arch/i386/stand/dosboot/Makefile
@@ -17,6 +17,7 @@ SRCS= main.c devopen.c exec.c
 CPPFLAGS+= -DSLOW	# for libz
 CPPFLAGS+= -DCOMPAT_386BSD_MBRPART
 CPPFLAGS+= -DXMS
+CPPFLAGS+= -DLIBSA_ENABLE_LS_OP
 #uncomment if there are problems with memory detection
 #CPPFLAGS+= -DCONSERVATIVE_MEMDETECT
 
@@ -30,7 +31,7 @@ SRCS+= getopt.c
 # XXX these should depend on the size of the image
 CPPFLAGS+= -DSTACK_START=0x1
 SAMISCCPPFLAGS+= -DHEAP_START=0x2 -DHEAP_LIMIT=0x5
-SAMISCMAKEFLAGS= SA_USE_CREAD=yes SA_INCLUDE_NET=no
+SAMISCMAKEFLAGS= SA_USE_CREAD=yes SA_INCLUDE_NET=no SA_ENABLE_LS_OP=yes
 I386MISCMAKEFLAGS= I386_INCLUDE_DOS=yes
 
 VERSIONFILE= ${.CURDIR}/version
diff --git a/sys/arch/i386/stand/dosboot/main.c b/sys/arch/i386/stand/dosboot/main.c
index 87054b0..e529903 100644
--- a/sys/arch/i386/stand/dosboot/main.c
+++ b/sys/arch/i386/stand/dosboot/main.c
@@ -323,12 +323,8 @@ void
 command_ls(char *arg)
 {
 	char *help = default_filename;
-	if (strcmp(current_fsmode, ufs)) {
-		printf(UFS only\n);
-		return;
-	}
 	default_filename = /;
-	ufs_ls(arg);
+	ls(arg);
 	default_filename = help;
 }
 
diff --git a/sys/arch/i386/stand/libsa/nfs.c b/sys/arch/i386/stand/libsa/nfs.c
index 18d1bd1..2cbf6ef 100644
--- a/sys/arch/i386/stand/libsa/nfs.c
+++ b/sys/arch/i386/stand/libsa/nfs.c
@@ -630,3 +630,12 @@ nfs_stat(struct open_file *f, struct stat *sb)
 
 	return (0);
 }
+
+#if defined(LIBSA_ENABLE_LS_OP)
+__compactcall void
+nfs_ls(struct open_file *f, const char *pattern)
+{
+	

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

2011-12-17 Thread Izumi Tsutsui
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

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.

  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