From: Monty <[EMAIL PROTECTED]>
Date: Thu, 11 Feb 1999 20:17:48 EST
The previous bug I'm referring to didn't occur in kernel code; it was
introduced by kernel code changes that resulted in a system header
change (and that was the bug).
Bugs don't happen where you intend them to. They happen where you
weren't paying attention. Stable == Code freeze, period.
Indeed, I guess people have been slow to learn the lessons of the 2.0
tree. People attempted to put in all sorts of network stack
enhancements, claimed they were "stable", didn't touch the API's, and
that ISP's wanted the extra performance in the middle of the 2.0
release. As it turns out, many ISP's refused to touch quite a few 2.0
releases as a result because they had all sorts of stability problems
that only showed up under heavy load, and weren't noticed when it wasn't
just the developers doing the testing.
Hopefully given the some of the disastrous releases in the 2.0 series,
people will learn and be a little bit more conservative about what goes
into 2.2. (Hopefully it won't be as conservative as the 1.2 series,
which caused the over-correction which we saw in 2.0, but ideally things
will be a happy medium.)
As far as devfs is concerned, I don't recall Linus ever making a
statement that he would put it into the 2.2 series, so Monty, you don't
need to panic. The reason why the discussion died down was that at
least in my perception, it seemed pretty clear it wasn't going to make
it into the 2.2 series, and that it was pointless to argue about it for
now. Certainly neither Richard nor I have managed to convince one
another, and so why continue to argue? There's enough other crap on
linux-kernel which makes the list nearly unreadable. :-)
My big complaint with the devfs idea is that it's putting a huge amount
of policy and configuration issues into the kernel, when you can do
nearly all of it outside of the kernel, in user space. Having a daemon
which ran at initialization time and initialized /dev would be far more
preferable, in my view. Furthermore, in the case of disks, if you are
going to be doing this kind of mapping, it should be reading the
filesystem labels and then creating devices which map at the filesystem
label. This way, if people move SCSI ID's around, or even add and
remove SCSI controllers, it won't matter, since the mount devices in
/etc/fstab would be defined in terms of volume labels in the ISO9660 or
ext2fs superblock. I've been working on a counterproposal in my spare
time, but I've unfortunately been a little too busy. If there's someone
who's interested in helping work on a counterproposal to devfs, let me
know....
- Ted
P.S. If someone can send me some quick and dirty code which can pull
off the ISO 9660 label, I'd greatly appreciate it. I've been meaning to
trace through the kernel code and pull it out, but what's there is
pretty complicated and runs through multiple functions. I need
something simple and self-contained, like this:
/*
* Check to see if it's an ext2 filesystem; if is, return the label.
*/
struct vol_label *get_ext2_label(unsigned char *page1,
unsigned char *page2)
{
struct ext2_super_block *sb;
static struct vol_label vol;
sb = (struct ext2_super_block *) page2;
if (le16_to_cpu(sb->s_magic) != EXT2_SUPER_MAGIC)
return 0;
vol.vol_type = VOL_EXT2;
vol.label = sb->s_volume_name;
memcpy(vol.vol_id, sb->s_uuid, sizeof(vol.vol_id));
return &vol;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
