From: Ed Sweetman <safemode2@comcast.net>
To: Casey Dahlin <cjdahlin@ncsu.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Unable to find root fs with libata only 2.6.18-mm3
Date: Sat, 07 Oct 2006 22:33:36 -0400 [thread overview]
Message-ID: <45286380.1060809@comcast.net> (raw)
In-Reply-To: <1160270544.10398.3.camel@localhost.localdomain>
Casey Dahlin wrote:
>> My question is, do I still need to compile in scsi disk/cdrom/generic
>> support into my kernel to get libata devices to work or is there some
>> other syntax i'm missing?
>>
>
> The initrd image provides the ramdisk image which contains modules not
> compiled into the kernel which are necessary to access the root
> filesystem. Man mkinitrd should explain how to set it up.
>
> Casey Dahlin
>
>
I'm not using initrd. All my drivers are compiled in that are needed at
boot. My question was in regards to the vagueness of just what the
Libata drivers require to actually work in a system. The libata drivers
will load and detect devices just fine without scsi compiled into the
kernel, they will however be completely useless since they wont be
assigning the drives detected on the busses to anything.
If libata is to be considered an alternative to scsi and ide (as it
should be, and as it is by it's location in the config now) then why is
it still treated as a subset of scsi in the config, requiring you to
compile in scsi drivers just like you would have had to do anyway if
libata was back in it's normal position under SCSI to make any actual
use of libata devices?
It seems like the move out of the scsi tree was pointless, and just adds
confusion since the driver tree isn't ready and hasn't got the makefiles
and kernel config scripts written to reuse the scsi drivers it requires
when someone wants a libata disk or cdrom or whatever device
transparently. If libata is to be on the same level as ide and scsi in
the config, then I shouldn't need to go into scsi to get a libata drive
to work.
It should be a matter of adding some config options under the libata
section for "disk support" and "cdrom support", etc and kconfig should
auto enable the scsi device options required. Maybe just move those
top level scsi drivers into some shared block layer directory since
eventually we'll be left with usb/libata/scsi and they'll all use those
top level drivers to do their device access.
next prev parent reply other threads:[~2006-10-08 2:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-08 0:52 Unable to find root fs with libata only 2.6.18-mm3 Ed Sweetman
2006-10-08 1:22 ` Casey Dahlin
2006-10-08 2:33 ` Ed Sweetman [this message]
2006-10-08 4:08 ` Tejun Heo
2006-10-08 4:18 ` Norberto Bensa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45286380.1060809@comcast.net \
--to=safemode2@comcast.net \
--cc=cjdahlin@ncsu.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox