I am asking why need to compile the following modules while I do not
have any SCSI device ?
Modules Loaded
rose netrom mkiss ax25 crc16 mach64 drm nfsd exportfs lockd nfs_acl
sunrpc ipv6 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
ne2k_pci 8390 snd_pcm_oss snd_mixer_oss snd_ens1371 gameport snd_rawmidi
snd_seq_device snd_ac97_codec snd_ac97_bus af_packet snd_pcm snd_timer
snd_page_alloc snd soundcore floppy ide_cd binfmt_misc loop supermount
ahci ata_piix libata scsi_mod dm_mod
cpufreq_ondemand cpufreq_conservative cpufreq_powersave speedstep_lib
freq_table intel_agp agpgart uhci_hcd usbcore evdev tsdev ext3 jbd
Hardware is :
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host
bridge (rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP
bridge (rev 03)
00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
00:0c.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06)
00:0d.0 Mass storage controller: Promise Technology, Inc. PDC20262
(FastTrak66/Ultra66) (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP
1X/2X (rev 5c)
ata_piix needs scsi_mod
When making menuconfig, the need to select SCSI submenu options seems
rather surprising to me for an IDE ATA disk only system.
Bernard Pidoux
Bernard Pidoux wrote:
> I am asking why need to compile the following modules while I do not
> have any SCSI device ?
Because your hardware is driven by a libata based driver. This means it
is a scsi bus driver and thus, requires mod_scsi and the scsi disk
module to access disks on the bus.
Bernard Pidoux wrote:
> I am asking why need to compile the following modules while I do not
> have any SCSI device ?
libata uses SCSI to provide a lot of infrastructure that it would
otherwise have to recreate. Also, using SCSI meant that it
automatically worked in existing installers.
Jeff
Jeff Garzik wrote:
> Bernard Pidoux wrote:
>> I am asking why need to compile the following modules while I do not
>> have any SCSI device ?
>
> libata uses SCSI to provide a lot of infrastructure that it would
> otherwise have to recreate. Also, using SCSI meant that it
> automatically worked in existing installers.
>
> Jeff
>
This confusion could easily be remedied by explaining the requirement in
the Help output for libata drivers/section. Also, making a dependency
in the menu (since there is one) or automatically selecting the required
scsi items when you select a libata driver would seem logical. As it is,
nothing is said of scsi requirements in menuconfig. Trying to boot a
machine without compiling the scsi drivers (something you're allowed to
do) results in a system that boots and initializes the ata busses but
can't communicate to any of the drives on them, (useless).
Then maybe later down the road, moving those scsi drivers shared by scsi
and libata to the generic block layer would seem logical. That is, when
ide is gone from the kernel and all the kernel speaks is scsi, there
would be no need to differentiate scsi from the generic block layer
devices, and no need to compile "scsi" drivers to have libata driver
support, eliminating any possible further confusion.
Ed Sweetman wrote:
> Jeff Garzik wrote:
>> Bernard Pidoux wrote:
>>> I am asking why need to compile the following modules while I do not
>>> have any SCSI device ?
>>
>> libata uses SCSI to provide a lot of infrastructure that it would
>> otherwise have to recreate. Also, using SCSI meant that it
>> automatically worked in existing installers.
>>
>> Jeff
>>
> This confusion could easily be remedied by explaining the requirement in
> the Help output for libata drivers/section. Also, making a dependency
> in the menu (since there is one) or automatically selecting the required
> scsi items when you select a libata driver would seem logical. As it is,
> nothing is said of scsi requirements in menuconfig. Trying to boot a
> machine without compiling the scsi drivers (something you're allowed to
> do) results in a system that boots and initializes the ata busses but
> can't communicate to any of the drives on them, (useless).
You can't select libata drivers without the SCSI core. However, you can
select libata drivers without the SCSI disk (sd) or the SCSI CD (sr)
drivers. However, that's a legitimate configuration as you may have only
hard disks, only CD drives, etc. and there would be no need to build the
other module. This isn't a major problem for most standard
configurations as those drivers are needed to handle things like USB and
FireWire flash drives, external HDs/optical drives, etc. anyway.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Robert Hancock wrote:
> Ed Sweetman wrote:
>> Jeff Garzik wrote:
>>> Bernard Pidoux wrote:
>>>> I am asking why need to compile the following modules while I do not
>>>> have any SCSI device ?
>>>
>>> libata uses SCSI to provide a lot of infrastructure that it would
>>> otherwise have to recreate. Also, using SCSI meant that it
>>> automatically worked in existing installers.
>>>
>>> Jeff
>>>
>> This confusion could easily be remedied by explaining the requirement
>> in the Help output for libata drivers/section. Also, making a
>> dependency in the menu (since there is one) or automatically
>> selecting the required scsi items when you select a libata driver
>> would seem logical. As it is, nothing is said of scsi requirements in
>> menuconfig. Trying to boot a machine without compiling the scsi
>> drivers (something you're allowed to do) results in a system that
>> boots and initializes the ata busses but can't communicate to any of
>> the drives on them, (useless).
>
> You can't select libata drivers without the SCSI core. However, you
> can select libata drivers without the SCSI disk (sd) or the SCSI CD
> (sr) drivers. However, that's a legitimate configuration as you may
> have only hard disks, only CD drives, etc. and there would be no need
> to build the other module. This isn't a major problem for most
> standard configurations as those drivers are needed to handle things
> like USB and FireWire flash drives, external HDs/optical drives, etc.
> anyway.
>
What's not a legitimate configuration is libata drivers, no low level
scsi drivers, no ide drivers and no sd,sr,sg drivers. Yet, that is the
configuration the kernel currently gives you. How is that more correct
than any of the 3 solutions I have suggested?
The point is there is nothing in the help section in libata to tell you
that these "scsi" drivers are needed for disk / cdrom / generic device
access in libata. Indeed, there is no obvious connection to the two.
Either configuration options need to be put in the libata directory that
would just select the drivers (libata disk, cdrom, generic configuration
options which would just enable the appropriate config variable, in
other words in the menu config have two config directives which would
enable the same drivers but be under different submenus to avoid
confusion), or a short description in the help dialog to tell users that
they have to enable those scsi drivers under the scsi section to use
their drivers under the libata section.
It's not safe to assume people will have those drivers compiled because
of usb or firewire or flash drives. Assuming that situation is 10 times
more problematic than any possible argument against just selecting those
scsi drivers automatically and letting the user deselect them as needed
when they select a libata driver.
Personaly, I prefer a help dialog blurb explaining that the user has to
enable certain scsi drivers to actually use their libata driven
devices. That, at the very least, I believe is necessary and not
asking much.
I've made patches before that impliment these trivial features in
menuconfig. In the grand scheme of things this isn't that important to
kernel development, but it's going to get more and more feedback as more
people move to libata and eventually it will be fixed in some manner
similar to those i've mentioned, I think it would just be better to do
it now than wait until the mailing list is filled with end users asking
why they need scsi when they obviously only have sata/ide and want to
use libata.
Ed Sweetman wrote:
> What's not a legitimate configuration is libata drivers, no low level
> scsi drivers, no ide drivers and no sd,sr,sg drivers. Yet, that is the
> configuration the kernel currently gives you. How is that more correct
> than any of the 3 solutions I have suggested?
You can't build libata without low-level SCSI drivers. CONFIG_ATA
automatically selects CONFIG_SCSI.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Robert Hancock wrote:
> Ed Sweetman wrote:
>> What's not a legitimate configuration is libata drivers, no low level
>> scsi drivers, no ide drivers and no sd,sr,sg drivers. Yet, that is
>> the configuration the kernel currently gives you. How is that more
>> correct than any of the 3 solutions I have suggested?
>
> You can't build libata without low-level SCSI drivers. CONFIG_ATA
> automatically selects CONFIG_SCSI.
>
config scsi isn't low level. There are no scsi controllers selected by
selecting config_ata. Mening, that the user hasn't bothered going into
the SCSI section. In effect you have a system that detects the ata
controllers but nothing that can use the drives on them. How is that a
valid system, a system where no drives are usable, but having some
mention of the configuration in the Help of libata or automatically
selecting those scsi_sd, sr, and sg drivers and letting the user
deselect them as needed instead of the other way around Not a valid are
more correct system?
No matter what when you select a scsi controller or libata controller
you are going to need to select one or more of those scsi device drivers
(sr,sg,sd) the issue is that when you are only using libata, you have no
reason to bother with the scsi section so it's not readily apparent that
you would need those block device drivers. I'm not saying we should
auto select them, but I am saying that auto selecting is way better than
keeping the kernel configuration the way it is and selecting none.
In the end the problem is in the layout of the config. SCSI is _THE_
device interface protocol but most people dont have scsi physical
interfaces. The kernel differentiates between the two inside the SCSI
section. This made sense before ide was marked for eventual replacement
by libata. Now everything uses that scsi top level for block device
access. That effectively makes those scsi block devices generic block
devices. SCSI and LIBATA sections should have configuration options
that are relevant to those physical devices and interfaces and not
require options from eachother's sections to get drivers in their own
sections to work. Massively shared config options shouldn't be stuck
in some sub menu below where all the things that use it are located.
But that's for some much later version of the kernel to deal with (when
ide is removed and such).
On Tue, 05 Dec 2006 21:46:54 -0500 Ed Sweetman wrote:
-ETOOMANYWORDS && -ENOPATCH, so here is one to consider.
Help text can also be added. <supply text>
This is similar to what USB storage already does.
---
From: Randy Dunlap <[email protected]>
Provide more clues about SCSI config options that are needed
for libata (SATA/PATA) drivers.
Signed-off-by: Randy Dunlap <[email protected]>
---
drivers/ata/Kconfig | 9 +++++++++
1 file changed, 9 insertions(+)
--- linux-2.6.19-git7.orig/drivers/ata/Kconfig
+++ linux-2.6.19-git7/drivers/ata/Kconfig
@@ -17,6 +17,15 @@ config ATA
that "speaks" the ATA protocol, also called ATA controller),
because you will be asked for it.
+comment "NOTE: ATA enables basic SCSI support; *however*,"
+ depends on ATA
+comment "+ 'SCSI disk support', 'SCSI tape support', or '"
+ depends on ATA
+comment "+ 'SCSI CDROM support' may also be needed,"
+ depends on ATA
+comment "+ depending on your hardware configuration."
+ depends on ATA
+
if ATA
config SATA_AHCI
Randy Dunlap wrote:
> On Tue, 05 Dec 2006 21:46:54 -0500 Ed Sweetman wrote:
>
> -ETOOMANYWORDS && -ENOPATCH, so here is one to consider.
> Help text can also be added. <supply text>
> This is similar to what USB storage already does.
>
>
I provided a patch a couple weeks ago when I brought this topic up
myself, but it was largely ignored because it wasn't the "add something
to help dialog" solution... I figured that the wording would be changed
anyway by the ide / libata guys or anyone else really involved with the
kernel. So I opted to provide a patch that did one of the other
solutions, namely, adding fake libata block devices in the libata
section that would merely enable the scsi blk dev variables as if you
had gone into the scsi section and did it the way it's currently done.
In any case, prior to this thread, I got basically no response on the
matter.
Your patch, however, should at least get into the next kernel revision
with any additional help text that may be of use.
Thanks.