CONFIG_SCSI_QLA_FC=y

Henrik Carlqvist

Robby Workman <newsgroups@rlworkman.net> wrote:
> I had this one marked for followup and intended to do some research on
> it before responding,

Thanks for your concern.

> That being the case, yes, if it's still not resolved in later kernels
> (check with 2.6.23.12 in -current), then report it to lkml.

I did report it to lkml. The response was that you can give
drivers the option to be compiled as modules without making it possible to
choose to have them compiled in the kernel. As such, there is no problem
with the kernel configuration method but the problem is that the qlogic
driver didn't exclude the option to be built into the kernel. At this
point I didn't do any further investigation.

If you want to read the lkml conversation it is at
http://groups.google.com/group/fa.li...434d6386774a8a

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc1(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

Henrik Carlqvist

Robby Workman <newsgroups@rlworkman.net> wrote:
> I had this one marked for followup and intended to do some research on
> it before responding,

Thanks for your concern.

> That being the case, yes, if it's still not resolved in later kernels
> (check with 2.6.23.12 in -current), then report it to lkml.

I did report it to lkml. The response was that you can give
drivers the option to be compiled as modules without making it possible to
choose to have them compiled in the kernel. As such, there is no problem
with the kernel configuration method but the problem is that the qlogic
driver didn't exclude the option to be built into the kernel. At this
point I didn't do any further investigation.

If you want to read the lkml conversation it is at
http://groups.google.com/group/fa.li...434d6386774a8a

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc1(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

Robby Workman

On 2007-10-06, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> In Slackware 12.0 the huge 2.6.21.5-smp kernel is configured with
> CONFIG_SCSI_QLA_FC=y
>
> This kernel is supposed to be useful without any initrd on almost any
> hardware. I have now tried to install Slackware 12 on a disk connected to
> a Qlogic 2312.
>
> Unfortunately this driver is unusable compiled into the kernel. The driver
> requires a firmware file loaded from a tool in userspace. However, even
> with an initrd containing that firmware in /lib/firmware/ the kernel will
> not be able to use it as the userspace tool isn't running while the kernel
> is booting.
>
> My conclusion is that the CONFIG_SCSI_QLA_FC driver is useless when
> compiled into the kernel. When compiled as a module it would be possible
> to create an initrd, but that initrd would need both the module, the
> firmware file and a userspace tool like udev to load the firmware when the
> module requests it.
>
> In my opinion this is almost to be considered a bug in the Linux kernel.
> It should not be possible to select a driver to be compiled into the
> kernel if that makes the driver useless.
>
> Do you think it would be worth the trouble to report this to lkml?


Henrik,

I had this one marked for followup and intended to do some research
on it before responding, but time hasn't been on my side. That being
the case, yes, if it's still not resolved in later kernels (check
with 2.6.23.12 in -current), then report it to lkml. If you go that
route, please CC me <rw _A_T_ rlworkman.net> on the initial mail so
that I'll also get replies.

Thanks,
-RW

Henrik Carlqvist

Robby Workman <newsgroups@rlworkman.net> wrote:

> On 2007-10-06, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>> My conclusion is that the CONFIG_SCSI_QLA_FC driver is useless when
>> compiled into the kernel.

> I had this one marked for followup and intended to do some research
> on it before responding,

By the way, speaking of things not needed in the huge kernel...

The huge kernel is supposed to be able to mount all different kinds of
strange root file systems without having to use an initrd.

A very nice cluster file system is ocfs2 and the huge kernel in Slackware
12 also has ocfs2 compiled into it. However, to be able to mount an ocfs2
file system some daemons first have to be started.

Those daemons are not included in Slackware 12 but can easily be
downloaded from oracle.com and compiled. The daemons are included in
ocfs2-tools. In that source package there are also some startup scripts
included to start the daemons, load the ocfs2 modules and mount all ocfs2
file systems.

Having ocfs2 compiled into the kernel means that loading ocfs2 modules
will fail and then the ocfs2 startup scripts will also fail. Of course it
is still possible to use such a huge kernel by modifying the startup
scripts to tolerate a kernel with built in support for ocfs2. However, I
really see no need to have ocfs2 compiled into the kernel. Having it in
the kernel is to no use as it is still necessary to have an initrd to
start the daemons. Also having it in the kernel makes some harm as it will
make it necessary to patch the default ocfs2 startup scripts.

Also, I don't think that anyone would want to have the root directory on a
cluster file system shared among more than one machines. What would be the
point of having the same /etc directory as another running machine?

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc1(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

Robby Workman

On 2008-01-03, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> <<snipped lots on OCFS>>

Good explanation - mail Pat.

-RW

Henrik Carlqvist

Robby Workman <newsgroups@rlworkman.net> wrote:

> On 2007-10-06, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>> My conclusion is that the CONFIG_SCSI_QLA_FC driver is useless when
>> compiled into the kernel.

> I had this one marked for followup and intended to do some research
> on it before responding,

By the way, speaking of things not needed in the huge kernel...

The huge kernel is supposed to be able to mount all different kinds of
strange root file systems without having to use an initrd.

A very nice cluster file system is ocfs2 and the huge kernel in Slackware
12 also has ocfs2 compiled into it. However, to be able to mount an ocfs2
file system some daemons first have to be started.

Those daemons are not included in Slackware 12 but can easily be
downloaded from oracle.com and compiled. The daemons are included in
ocfs2-tools. In that source package there are also some startup scripts
included to start the daemons, load the ocfs2 modules and mount all ocfs2
file systems.

Having ocfs2 compiled into the kernel means that loading ocfs2 modules
will fail and then the ocfs2 startup scripts will also fail. Of course it
is still possible to use such a huge kernel by modifying the startup
scripts to tolerate a kernel with built in support for ocfs2. However, I
really see no need to have ocfs2 compiled into the kernel. Having it in
the kernel is to no use as it is still necessary to have an initrd to
start the daemons. Also having it in the kernel makes some harm as it will
make it necessary to patch the default ocfs2 startup scripts.

Also, I don't think that anyone would want to have the root directory on a
cluster file system shared among more than one machines. What would be the
point of having the same /etc directory as another running machine?

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc1(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

Robby Workman

On 2007-10-06, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> In Slackware 12.0 the huge 2.6.21.5-smp kernel is configured with
> CONFIG_SCSI_QLA_FC=y
>
> This kernel is supposed to be useful without any initrd on almost any
> hardware. I have now tried to install Slackware 12 on a disk connected to
> a Qlogic 2312.
>
> Unfortunately this driver is unusable compiled into the kernel. The driver
> requires a firmware file loaded from a tool in userspace. However, even
> with an initrd containing that firmware in /lib/firmware/ the kernel will
> not be able to use it as the userspace tool isn't running while the kernel
> is booting.
>
> My conclusion is that the CONFIG_SCSI_QLA_FC driver is useless when
> compiled into the kernel. When compiled as a module it would be possible
> to create an initrd, but that initrd would need both the module, the
> firmware file and a userspace tool like udev to load the firmware when the
> module requests it.
>
> In my opinion this is almost to be considered a bug in the Linux kernel.
> It should not be possible to select a driver to be compiled into the
> kernel if that makes the driver useless.
>
> Do you think it would be worth the trouble to report this to lkml?


Henrik,

I had this one marked for followup and intended to do some research
on it before responding, but time hasn't been on my side. That being
the case, yes, if it's still not resolved in later kernels (check
with 2.6.23.12 in -current), then report it to lkml. If you go that
route, please CC me <rw _A_T_ rlworkman.net> on the initial mail so
that I'll also get replies.

Thanks,
-RW

Robby Workman

On 2008-01-03, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> <<snipped lots on OCFS>>

Good explanation - mail Pat.

-RW

Henrik Carlqvist

Robby Workman <newsgroups@rlworkman.net> wrote:

> On 2007-10-06, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>> My conclusion is that the CONFIG_SCSI_QLA_FC driver is useless when
>> compiled into the kernel.

> I had this one marked for followup and intended to do some research
> on it before responding,

By the way, speaking of things not needed in the huge kernel...

The huge kernel is supposed to be able to mount all different kinds of
strange root file systems without having to use an initrd.

A very nice cluster file system is ocfs2 and the huge kernel in Slackware
12 also has ocfs2 compiled into it. However, to be able to mount an ocfs2
file system some daemons first have to be started.

Those daemons are not included in Slackware 12 but can easily be
downloaded from oracle.com and compiled. The daemons are included in
ocfs2-tools. In that source package there are also some startup scripts
included to start the daemons, load the ocfs2 modules and mount all ocfs2
file systems.

Having ocfs2 compiled into the kernel means that loading ocfs2 modules
will fail and then the ocfs2 startup scripts will also fail. Of course it
is still possible to use such a huge kernel by modifying the startup
scripts to tolerate a kernel with built in support for ocfs2. However, I
really see no need to have ocfs2 compiled into the kernel. Having it in
the kernel is to no use as it is still necessary to have an initrd to
start the daemons. Also having it in the kernel makes some harm as it will
make it necessary to patch the default ocfs2 startup scripts.

Also, I don't think that anyone would want to have the root directory on a
cluster file system shared among more than one machines. What would be the
point of having the same /etc directory as another running machine?

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc1(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

Robby Workman

On 2008-01-03, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> <<snipped lots on OCFS>>

Good explanation - mail Pat.

-RW