Messages in this thread | | | From | (david parsons) | Subject | Re: Kernel Panic, root fs.. | Date | 17 Aug 1999 16:15:07 -0700 |
| |
In article <linux.kernel.Pine.LNX.3.95.990817155201.31582A-100000@chaos.analogic.com>, Richard B. Johnson <root@chaos.analogic.com> wrote: >On 17 Aug 1999, david parsons wrote: > >> In article <linux.kernel.Pine.LNX.3.95.990817090722.13436A-100000@chaos.analogic.com>, >> Richard B. Johnson <root@chaos.analogic.com> wrote: >> >On Tue, 17 Aug 1999, Dan Hollis wrote: >> >> >> <QUOTE> >> >> Kernel Panic: Couldnt mount /dev/sda1 on root fs, perhaps you forgot to >> >> compile in scsi support? >> >> </QUOTE> >> >> >Big strings mean big kernels. Not too good. The kernel doesn't >> >know, and *** must not know *** about 'dev/sda1'. >> >> Too late, I'm afraid. >> >> The de facto standard names are already known to the kernel (cf: >> init/main.c::name_to_kdev_t(), just for an example) and it is >> somewhat silly to have this one place spit out a magic code after >> the kernel has just finished telling you (for example) >> >> sda : READ CAPACITY failed. >> sda : status = 1, message = 00, host = 0, driver = 28 >> sda : extended sense code = 2 >> sda : block size assumed to be 512 bytes, disk size 1GB. >> Partition check: >> sda:scsidisk I/O error: dev 08:00, sector 0 >> unable to read partition table >> hda: hda1 hda2 hda3 >>
>Yep. And it shows you why it's not correct! The SCSI disk devices >are not named hda: hda1, hda3, etc.,
I think you may misunderstand; the klog snippet I posted, which does show that the kernel already knows about, is from one of my development workstations, and not from the offending machine.
Even leaving aside my opinion that major and minor numbers are the most odious sort of black magic, the kernel as it stands today knows about the de facto standard for device names, and already has code that can decode and encode the black magic. The code bloat needed to tuck skeleton tables for majors that aren't compiled in becomes nothing more than a simple major/minor->name mapping, which is probably a whopping 4k.
I'd produce a patch, but I've already got a large pile of patches waiting for Linux to notice them.
____ david parsons \bi/ It's not bloat when it leads to clearer diagnostics. \/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |