[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <460B7C08.6030805@tls.msk.ru>
Date: Thu, 29 Mar 2007 12:42:48 +0400
From: Michael Tokarev <mjt@....msk.ru>
To: owl-users@...ts.openwall.com
CC: galaxy@...nwall.com, gremlin@...mlin.ru
Subject: Re: Re: [owl-devel] Testing User Guide & installer
Grigoriy Strokin wrote:
[]
> I have tried to include anything SATA-related into the kernel as
> built-in rather than as modules, but it still doesn't work. Either I've
> missed something, or this initrd does more than just loading required
> modules: since the disk is eventually seen as /dev/sda, I suppose that
> initrd configures some kind of SCSI emulation in addition to loading
> required modules.
JFYI: All SATA-related stuff (and new PATA aka IDE, but based on libata)
will be /dev/sd* (and /dev/sr* for cd-roms), not /dev/hd*. That to say --
If, on the same controller, you've both /dev/hd* and /dev/sd*, that means
that some "parts" of the controller are served by [SP]ATA driver, and some
by IDE driver. Which doesn't quite work right, and such an ability has
been removed from recent 2.6.* kernels, simplifying and cleaning up the
code *alot*.
Note that this all has - almost - nothing to do with initrd/initramfs.
Whichever modules you'll load (or compile into the kernel), those devices
will be present. Order does matter as well - having both IDE and PATA
modules (or built-in), you can have EITHER /dev/sd* OR /dev/hd* -
depending on which module has been loaded (or driver probed for
built-in drivers) first.
The only way initrd is involved is that it has to load the modules
(if not built-in) -- but that's all, it can't do more than loading
wrt setting up - at least IDE/[SP]ATA - devices.
/mjt
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
