2.2.X patch query

2.2.X patch query

[Riley Williams]

Hi Alan.

You may remember a while back a suggestion that panic messages be
dumped to floppy so they can be read afterwards.

I've been looking into this idea for a while, in between working on my
plans to get married, and looking for a job somewhere, and I think I
have the bones of it laid out now.

I'm NOT planning on making panics automatically dump to floppy. What I
was looking at instead was to add a SysRq option to dump the current
syslog buffer to floppy. This would be available at any time, but ONLY
if the kernel has SYSRQ support compiled in, and has additionally
enabled CONFIG_SYSRQ_DUMPLOG (which appears when SYSRQ is enabled). In
addition, it would need to be enabled at runtime, probably by writing
to a root-owned /proc file with 0600 permissions.

Before I go any further with this, I would like to ask a few questions
relating to it:

 1. Is there any likelihood of this making it into the official
    kernel, or am I just wasting my time?

 2. Would I be right in thinking it's too late for either the
    2.2 or 2.4 kernels ???

Assuming it'd be of interest to Linus and yourself...

 3. My investigations so far have indicated that the current
    syslog buffer at 16k is too small to guarantee that all
    the relevant messages are still there. I would therefore
    be looking at increasing this to at least 32k, and would
    probably include a config menu to select the size to use
    if CONFIG_SYSRQ_DUMPLOG is enabled, offering 32k, 64k,
    128k, 256k, 512k and 1M as options.

    Would this cause any problems?

 4. My choice would be to use SYSRQ-D to activate this. Are
    there any other plans for that combination, that you are
    aware of?

 5. I was wondering about providing some means of selecting
    whether to dump to /dev/fd0 or /dev/fd1 (or others if
    present). What would be your opinion on this?

 6. A while back, I developed a high-level floppy formatter
    that produces a non-standard DOS-compatible format that
    allows 1436k of data on a 1440k floppy, and produced a
    bash script that would produce disks formatted in this
    format.

    My current plans are for SYSRQ-D to raw write direct to
    /dev/fd0 and effectively reformat the disks in this
    format, dropping the log file thereon in the process. I
    don't plan on doing the low-level format, just the
    high-level one.

    Can you see anything wrong with this idea?

Best wishes from Riley.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.X patch query

[Andreas Dilger]

Riley Williams writes:
> I'm NOT planning on making panics automatically dump to floppy. What I
> was looking at instead was to add a SysRq option to dump the current
> syslog buffer to floppy. This would be available at any time, but ONLY
> if the kernel has SYSRQ support compiled in, and has additionally
> enabled CONFIG_SYSRQ_DUMPLOG (which appears when SYSRQ is enabled). In
> addition, it would need to be enabled at runtime, probably by writing
> to a root-owned /proc file with 0600 permissions.

Just as an FYI, there is a patch that does essentially what you are
looking at: kmsgdump, by Willy Tarreau.  It does a syslog dump to
floppy with SysRq-D, and has the excellent feature that it writes a
(simple) MS-DOS formatted floppy, which also has a "pass-through"
boot sector, so you can leave it in the floppy drive and it will not
halt booting.  You can have syslog sizes up to 64kB.  It also supports
printing to the printer port.

http://www-miaif.lip6.fr/willy/pub/linux-patches/kmsgdump/

This would actually be very handy in conjunction with the "loadable
sysrq functions" patch that has been posted here a couple of times.

I suspect that such a patch wouldn't make it into 2.2 or 2.4.  I also
don't see why you want to have a strangely formatted floppy, since even
a regular 1.44 format will hold your proposed maximum 1MB buffer.  Since
the printk buffer is pinned kernel memory, you probably don't want that
any larger (if 1MB at all).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.X patch query

[Horst von Brand]

Riley Williams <rhw@MemAlpha.CX> said:

[...]

> Before I go any further with this, I would like to ask a few questions
> relating to it:
> 
>  1. Is there any likelihood of this making it into the official
>     kernel, or am I just wasting my time?

Depends, I'd say... perhaps after a long shakeout and much use.

>  2. Would I be right in thinking it's too late for either the
>     2.2 or 2.4 kernels ???

No way.

> Assuming it'd be of interest to Linus and yourself...

[...]

>  5. I was wondering about providing some means of selecting
>     whether to dump to /dev/fd0 or /dev/fd1 (or others if
>     present). What would be your opinion on this?

Keep it as simple as possible. I'd leave the option open if not hard, but
not implement it at all at first.

>  6. A while back, I developed a high-level floppy formatter
>     that produces a non-standard DOS-compatible format that
>     allows 1436k of data on a 1440k floppy, and produced a
>     bash script that would produce disks formatted in this
>     format.
> 
>     My current plans are for SYSRQ-D to raw write direct to
>     /dev/fd0 and effectively reformat the disks in this
>     format, dropping the log file thereon in the process. I
>     don't plan on doing the low-level format, just the
>     high-level one.

KISS, again. What use is a non-standard 1436Kb DOS format when writing at
most 1Mb? I'd just dump it raw to /dev/fd0, whoever wants to read it later
will have all kinds of tools at hand.

Remember:

- Bloat
- This will have to work even in a thoroughly hosed system to be of any use
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.X patch query (with initial PATCH against 2.2.17)

[Riley Williams]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2993 bytes --]

Hi Horst.

 >> Before I go any further with this, I would like to ask a few
 >> questions relating to it:

 >> 1. Is there any likelihood of this making it into the official
 >>    kernel, or am I just wasting my time?

 > Depends, I'd say... perhaps after a long shakeout and much use.

Fair enough - I'd expect that much...

 >> 2. Would I be right in thinking it's too late for either the
 >>    2.2 or 2.4 kernels ???

 > No way.

Good...

I've included a patch against 2.2.17 that deals with all of the
existing files and implements a version of this facility that just
prints "(Not yet implemented)" into the SysLog. The final version will
basically consist of this patch with the printk("Not yet implemeted")
replaced by a call to the routine to actually perform the dump, plus a
new file kernel/dumplog.c containing the said routine.

Note that this patch tweaks ALL of the current architecture config.in
files to replace the CONFIG_MAGIC_SYSRQ definition with a command to
include the new arch/sysrq.in file at that point, and all the options
relating to SYSRQ are in this new file instead.

 >> 5. I was wondering about providing some means of selecting
 >>    whether to dump to /dev/fd0 or /dev/fd1 (or others if
 >>    present). What would be your opinion on this?

 > Keep it as simple as possible. I'd leave the option open if not
 > hard, but not implement it at all at first.

OK. Initially, I'll look at dropping it strictly to /dev/fd0 and leave
the /dev/fd1 code until later.

 >> 6. A while back, I developed a high-level floppy formatter
 >>    that produces a non-standard DOS-compatible format that
 >>    allows 1436k of data on a 1440k floppy, and produced a
 >>    bash script that would produce disks formatted in this
 >>    format.

 >>    My current plans are for SYSRQ-D to raw write direct to
 >>    /dev/fd0 and effectively reformat the disks in this
 >>    format, dropping the log file thereon in the process. I
 >>    don't plan on doing the low-level format, just the
 >>    high-level one.

 > KISS, again. What use is a non-standard 1436Kb DOS format when
 > writing at most 1Mb?

The said floppy formatter also works with other capacity disks, and
always minimises the system overhead for the disk size.

Also, part of my plan was to check that the disk is already in this
non-standard format, and refuse to dump if not. This would ensure that
doing so didn't overwrite somebody's master boot disk by accident, as
such disks will not normally be in this non-standard format.

 > I'd just dump it raw to /dev/fd0, whoever wants to read it later
 > will have all kinds of tools at hand.

 > Remember:

 > - Bloat

That's one reason why I was glad to note the error in the comments in
kernel/printk.c that I sent a patch to correct last week - this patch
will be MUCH simpler as a result.

 > - This will have to work even in a thoroughly hosed system to be
 >   of any use

It's for precicely that reason that I'm working on it.

Best wishes from Riley.

[-- Attachment #2: Type: TEXT/PLAIN, Size: 7442 bytes --]

--- linux-2.2.17/arch/alpha/config.in~	Mon Sep  4 18:39:16 2000
+++ linux-2.2.17/arch/alpha/config.in	Tue Oct 31 13:18:57 2000
@@ -299,8 +299,7 @@
 if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
   tristate 'Kernel FP software completion' CONFIG_MATHEMU
 else
   define_bool CONFIG_MATHEMU y
 fi
-
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
 endmenu
--- linux-2.2.17/arch/arm/config.in~	Wed Jun  7 22:26:42 2000
+++ linux-2.2.17/arch/arm/config.in	Tue Oct 31 13:19:11 2000
@@ -214,7 +214,7 @@
 mainmenu_option next_comment
 comment 'Kernel hacking'
 
 bool 'Debug kernel errors' CONFIG_DEBUG_ERRORS
 #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
 endmenu
--- linux-2.2.17/arch/i386/config.in~	Mon Sep  4 18:39:16 2000
+++ linux-2.2.17/arch/i386/config.in	Tue Oct 31 13:29:03 2000
@@ -204,8 +204,7 @@
 
 mainmenu_option next_comment
 comment 'Kernel hacking'
 
 #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
 endmenu
-
--- linux-2.2.17/arch/m68k/config.in~	Wed Jun  7 22:26:42 2000
+++ linux-2.2.17/arch/m68k/config.in	Tue Oct 31 13:19:27 2000
@@ -448,8 +448,8 @@
 
 mainmenu_option next_comment
 comment 'Kernel hacking'
 
 #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
 bool 'Remote debugging support' CONFIG_KGDB
 endmenu
--- linux-2.2.17/arch/mips/config.in~	Wed Jun  7 22:26:42 2000
+++ linux-2.2.17/arch/mips/config.in	Tue Oct 31 13:19:42 2000
@@ -303,7 +303,7 @@
   bool ' Build fp execption handler module' CONFIG_MIPS_FPE_MODULE
 fi
 if [ "$CONFIG_SERIAL" = "y" ]; then
   bool 'Remote GDB kernel debugging' CONFIG_REMOTE_DEBUG
 fi
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
 endmenu
--- linux-2.2.17/arch/ppc/config.in~	Mon Sep  4 18:39:16 2000
+++ linux-2.2.17/arch/ppc/config.in	Tue Oct 31 13:20:01 2000
@@ -195,9 +195,9 @@
 endmenu
 
 mainmenu_option next_comment
 comment 'Kernel hacking'
 
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
 bool 'Include kgdb kernel debugger' CONFIG_KGDB
 bool 'Include xmon kernel debugger' CONFIG_XMON
 endmenu
--- linux-2.2.17/arch/s390/config.in~	Wed Jun  7 22:26:42 2000
+++ linux-2.2.17/arch/s390/config.in	Tue Oct 31 13:20:30 2000
@@ -66,8 +66,9 @@
   int ' Profile shift count' CONFIG_PROFILE_SHIFT 2
 fi
 if [ "$CONFIG_CTC" = "y" ]; then
   bool 'Remote GDB kernel debugging' CONFIG_REMOTE_DEBUG
 fi
-# this does not work. bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+##### this does not work.
+# source ../sysrq.in
+#####
 endmenu
-
--- linux-2.2.17/arch/sparc/config.in~	Wed Jun  7 22:26:42 2000
+++ linux-2.2.17/arch/sparc/config.in	Tue Oct 31 13:20:43 2000
@@ -219,8 +219,7 @@
 endmenu
 
 mainmenu_option next_comment
 comment 'Kernel hacking'
 
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
 endmenu
-
--- linux-2.2.17/arch/sparc64/config.in~	Mon Sep  4 18:39:16 2000
+++ linux-2.2.17/arch/sparc64/config.in	Tue Oct 31 13:21:02 2000
@@ -282,8 +282,8 @@
 endmenu
 
 mainmenu_option next_comment
 comment 'Kernel hacking'
 
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
 #bool 'ECache flush trap support at ta 0x72' CONFIG_EC_FLUSH_TRAP
 endmenu
--- linux-2.2.17/arch/sysrq.in~	Thu Jan  1 01:00:00 1970
+++ linux-2.2.17/arch/sysrq.in	Tue Oct 31 13:23:52 2000
@@ -0,0 +1,22 @@
+#
+# For a description of the syntax of this configuration file,
+# see Documentation/kbuild/config-language.txt.
+#
+# This section is included from the various arch-dependant
+# config.in files, and provides the common SysRq options.
+# This ensures that these options have a common description.
+#
+bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+if [ "$CONFIG_MAGIC_SYSRQ" = "y" -a "$CONFIG_EXPERIMENTAL" = "y" ]; then
+    bool '  Enable dump of syslog to floppy (EXPERIMENTAL)' CONFIG_MAGIC_SYSRQ_DUMPLOG
+    if [ "$CONFIG_MAGIC_SYSRQ_DUMPLOG" = "y" ]; then
+	choice '    SysLog buffer size'			\
+		" 32k CONFIG_MAGIC_SYSRQ_LOG_32K	\
+		  64k CONFIG_MAGIC_SYSRQ_LOG_64K	\
+		 128k CONFIG_MAGIC_SYSRQ_LOG_128K	\
+		 256k CONFIG_MAGIC_SYSRQ_LOG_256K	\
+		 512k CONFIG_MAGIC_SYSRQ_LOG_512K	\
+		1024k CONFIG_MAGIC_SYSRQ_LOG_1M		\
+		2048k CONFIG_MAGIC_SYSRQ_LOG_2M" 32k
+    fi
+fi
--- linux-2.2.17/Documentation/Configure.help~	Mon Sep  4 18:39:15 2000
+++ linux-2.2.17/Documentation/Configure.help	Tue Oct 31 13:26:43 2000
@@ -10397,10 +10397,17 @@
   immediately or dump some status information). This is accomplished
   by pressing various keys while holding SysRq (Alt+PrintScreen). The
   keys are documented in Documentation/sysrq.txt. Don't say Y unless
   you really know what this hack does.
 
+System Request facility to dump the SysLog to /dev/fd0
+CONFIG_MAGIC_SYSRQ_DUMPLOG
+  If you say Y here, you will have the ability to dump that part of
+  the system log that is still in the kernel buffer area to the disc
+  in /dev/fd0 which will normally give you the ability to capture the
+  kernel panic messages that normally result in a system lockup.
+
 ISDN subsystem
 CONFIG_ISDN
   ISDN ("Integrated Services Digital Networks", called RNIS in France)
   is a special type of fully digital telephone service; it's mostly
   used to connect to your Internet service provider (with SLIP or
--- linux-2.2.17/drivers/char/sysrq.c~	Thu May  4 01:16:39 2000
+++ linux-2.2.17/drivers/char/sysrq.c	Tue Oct 31 13:11:35 2000
@@ -131,16 +131,25 @@
 	case 'l':					    /* L -- kill all processes including init */
 		printk("Kill ALL Tasks (even init)\n");
 		send_sig_all(SIGKILL, 1);
 		orig_log_level = 8;
 		break;
+#ifdef CONFIG_MAGIC_SYSRQ_DUMPLOG
+	case 'd':					    /* D -- dump syslog to /dev/fd0 */
+		printk("Dump SysLog to /dev/fd0\n");
+		printk("(Not yet implemented)\n");
+		break;
+#endif
 	default:					    /* Unknown: help */
 		if (kbd)
 			printk("unRaw ");
 #ifdef CONFIG_VT
 		if (tty)
 			printk("saK ");
+#endif
+#ifdef CONFIG_MAGIC_SYSRQ_DUMPLOG
+		printk("Dump ");
 #endif
 		printk("Boot ");
 		if (sysrq_power_off)
 			printk("Off ");
 		printk("Sync Unmount showPc showTasks showMem loglevel0-8 tErm kIll killalL\n");
--- linux-2.2.17/kernel/printk.c~	Sat Oct 28 10:01:20 2000
+++ linux-2.2.17/kernel/printk.c	Tue Oct 31 13:15:01 2000
@@ -20,11 +20,36 @@
 #include <linux/console.h>
 #include <linux/init.h>
 
 #include <asm/uaccess.h>
 
-#define LOG_BUF_LEN	(16384)
+#ifndef CONFIG_MAGIC_SYSRQ_DUMPLOG
+#	define LOG_BUF_LEN	(16 * 1024)
+#else
+#    ifdef CONFIG_MAGIC_SYSRQ_LOG_32K
+#	define LOG_BUF_LEN	(32 * 1024)
+#    endif
+#    ifdef CONFIG_MAGIC_SYSRQ_LOG_64K
+#	define LOG_BUF_LEN	(64 * 1024)
+#    endif
+#    ifdef CONFIG_MAGIC_SYSRQ_LOG_128K
+#	define LOG_BUF_LEN	(128 * 1024)
+#    endif
+#    ifdef CONFIG_MAGIC_SYSRQ_LOG_256K
+#	define LOG_BUF_LEN	(256 * 1024)
+#    endif
+#    ifdef CONFIG_MAGIC_SYSRQ_LOG_512K
+#	define LOG_BUF_LEN	(512 * 1024)
+#    endif
+#    ifdef CONFIG_MAGIC_SYSRQ_LOG_1M
+#	define LOG_BUF_LEN	(1 * 1024 * 1024)
+#    endif
+#    ifdef CONFIG_MAGIC_SYSRQ_LOG_2M
+#	define LOG_BUF_LEN	(2 * 1024 * 1024)
+#    endif
+#endif
+
 #define LOG_BUF_MASK	(LOG_BUF_LEN-1)
 
 static char buf[1024];
 
 /* printk's without a loglevel use this.. */

Re: 2.2.X patch query (with initial PATCH against 2.2.17)

[Dominik Kubla]

On Tue, Oct 31, 2000 at 01:38:56PM +0000, Riley Williams wrote:
...
> Also, part of my plan was to check that the disk is already in this
> non-standard format, and refuse to dump if not. This would ensure that
> doing so didn't overwrite somebody's master boot disk by accident, as
> such disks will not normally be in this non-standard format.

Just write a magic number somewhere to the disk and mark these blocks
bad in the fat. Then just check if the blocks are marked as bad and
contain the magic number. No need for a special disk format per se...

Yours,
  Dominik Kubla
-- 
http://petition.eurolinux.org/index_html - No Software Patents In Europe!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.X patch query (with initial PATCH against 2.2.17)

[Horst von Brand]

Dominik Kubla <dominik.kubla@uni-mainz.de> said:
> On Tue, Oct 31, 2000 at 01:38:56PM +0000, Riley Williams wrote:
> ...
> > Also, part of my plan was to check that the disk is already in this
> > non-standard format, and refuse to dump if not. This would ensure that
> > doing so didn't overwrite somebody's master boot disk by accident, as
> > such disks will not normally be in this non-standard format.

> Just write a magic number somewhere to the disk and mark these blocks
> bad in the fat. Then just check if the blocks are marked as bad and
> contain the magic number. No need for a special disk format per se...

Why any filesystem at all? Just dump the whole on the diskette in the
drive. If root doesn't know what they are doing fiddling with SysRq, they
deserve it in any case. No FAT, MS-DOS, VFAT or whatever. Just a plain
formated diskette. Remember, this has to be absolutely as simple and robust
as possible, and have minimal impact on the rest of the kernel (no "must
now pull in RW-floppy-format + fat + msdos modules to do SysRq-D", no
"<foo> must be built into the kernel for SysRq-D to work" (at most "floppy
in kernel", more can be hard to swallow in limited environments where this
will be most needed as the only/principal way of looking at logs)).
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.X patch query (with initial PATCH against 2.2.17)

[Andreas Dilger]

Dr. Horst H. von Brand writes:
> Dominik Kubla <dominik.kubla@uni-mainz.de> said:
> > On Tue, Oct 31, 2000 at 01:38:56PM +0000, Riley Williams wrote:
> > ...
> > > Also, part of my plan was to check that the disk is already in this
> > > non-standard format, and refuse to dump if not. This would ensure that
> > > doing so didn't overwrite somebody's master boot disk by accident, as
> > > such disks will not normally be in this non-standard format.
> 
> > Just write a magic number somewhere to the disk and mark these blocks
> > bad in the fat. Then just check if the blocks are marked as bad and
> > contain the magic number. No need for a special disk format per se...
> 
> Why any filesystem at all? Just dump the whole on the diskette in the
> drive. If root doesn't know what they are doing fiddling with SysRq, they
> deserve it in any case. No FAT, MS-DOS, VFAT or whatever. Just a plain
> formated diskette. Remember, this has to be absolutely as simple and robust
> as possible, and have minimal impact on the rest of the kernel (no "must
> now pull in RW-floppy-format + fat + msdos modules to do SysRq-D", no
> "<foo> must be built into the kernel for SysRq-D to work" (at most "floppy
> in kernel", more can be hard to swallow in limited environments where this
> will be most needed as the only/principal way of looking at logs)).

Actually, as I had previously sent to Riley (privately), the kmsgdump
patch does exactly what I would want it to do:

1) can dump to a raw floppy disk (cat or dd to retrieve later)
2) can check for a labelled FAT floppy (via MS-DOS DISKLABEL)
   - will only dump to FAT floppy if magic label is correct (avoid overwrite)
   - will dump in "MS-DOS" FAT format (see below)
3) can be set up to automatically dump and reboot
   - writes a simple boot loader at start of FAT floppy which causes BIOS
     to continue booting, so we do not hang computer at boot after dump
4) FAT format is "normal" in that mcopy or msdos modules can read it
   - does not need fat/msdos modules installed because it is not a fully
     formatted floppy, just enough to store 1 dump file in root directory
5) has console mode to view syslogs (with scrolling, etc) after
   crash/SysRQ-D in case no floppy is on machine
   - can also print logs to printer

http://www-miaif.lip6.fr/willy/pub/linux-patches/kmsgdump/

It has a 2.2 and 2.3 version (nothing recently, probably because of 2.4
freeze).  It would probably be a prime candidate for the "loadable SysRq
modules" patch that has been posted to l-k the last couple of weeks.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.X patch query (with initial PATCH against 2.2.17)

[Riley Williams]

Hi Horst.

 >>> Also, part of my plan was to check that the disk is
 >>> already in this non-standard format, and refuse to
 >>> dump if not. This would ensure that doing so didn't
 >>> overwrite somebody's master boot disk by accident, as
 >>> such disks will not normally be in this non-standard
 >>> format.

 >> Just write a magic number somewhere to the disk and
 >> mark these blocks bad in the fat. Then just check if
 >> the blocks are marked as bad and contain the magic
 >> number. No need for a special disk format per se...

There's much better reasons for using a special format than
that. Horst has hit the main one - code simplicity.

 > Why any filesystem at all? Just dump the whole on the
 > diskette in the drive. If root doesn't know what they
 > are doing fiddling with SysRq, they deserve it in any
 > case. No FAT, MS-DOS, VFAT or whatever. Just a plain
 > formated diskette.

That argument's a non-starter in my book - the difference
between writing a raw floppy and one with an MS-DOS type 
filesystem on it comes down to prepending a fixed header to
the data, nothing more.

The MS-DOS type of filesystem is one of the simplest one can
get, but the standard version thereof used with floppies is
just a PITA to work with. What I've done is to remain
compatible with it, but tweak the parameters to produce a
much simpler version thereof.

 > Remember, this has to be absolutely as simple and
 > robust as possible, and have minimal impact on the
 > rest of the kernel...

That's precicely why I'm using the modified filesystem I
referred to in a previous post. Can I suggest that, before
you complain any more about it, you actually try it out? I
wrote and released the formatter that produces the said
filesystem many months ago now, and can easily send you a
copy to play with. It's also its own source code, as the
said formatter is written entirely as a BASH shell script,
and the fact that it's done that way should speak for itself
as to the simplicity of the format used.

Basically, from a programming point of view, it comes down
to writing a raw disk, but prepending a fixed header (size
4k on a 1440k floppy) to the log being written, and gaining
a LOT of advantages with virtually no disadvantages.

For reference, here's a few of the features of the said
format:

 1. Disks in this format can be read from and written
    to by MS-DOS 2.11, 3.10, 5.00 and 6.22 and by Windows
    95, 98 and NT (all tested).

 2. Disks formatted in this format do NOT use any extra
    tracks or sectors per track over those formatted in
    the standard format.

 3. From a programmer's viewpoint, the resulting format
    is MUCH simpler to handle than the standard one.

 4. The data area available on the disk is maximised for
    any particular physical layout.

The first two features mean that the resulting disks can be
used on ANY standard floppy drive. The third means that the
so-called bloat just will not exist.

The fourth is the one that people seem to have concentrated
on, but is irrelevant for this application. That particular
feature is only really relevant for backup disks.

 > ...(no "must now pull in RW-floppy-format + fat +
 > msdos modules to do SysRq-D", no "<foo> must be built
 > into the kernel for SysRq-D to work" (at most "floppy
 > in kernel", more can be hard to swallow in limited
 > environments where this will be most needed as the
 > only/principal way of looking at logs)).

None of that is required to use this format - it is designed
to (a) be fully compatible with the requirements of MS-DOS
2.00 and later (including WIndows 9x and NT, and (b) be as
simple as possible for the programmer to code.

Best wishes from Riley.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/