Hello All,
We are releasing the megaraid unified driver version 2.20.0.0.
The source is available at our public ftp site:
ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-unified-2.20.0.B1.04.0
7.2004/
Kernels:
---------
This driver is primarily for lk 2.6. While this also works on lk 2.4
this is not a replacement for the extant 2.x driver on 2.4 kernel.
Thanks to:
-----------
This driver has been designed according to the great inputs by
Jeff Garzik and Matt Domsch. 'readme' in the source tgz has more
details. Thanks in advance also to Paul Wagland for the sysfs
support that he agreed to add.
Near-term goals:
------------------
i. A new class of controllers will be added under this umbrella.
ii. Paul Wagland has agreed to start off adding sysfs support to
the common module.
iii. Information exported via sysfs will be fully augmented to allow
sophisticated monitoring.
iv. Write support will be added through sysfs.
v. We are NOT planning to have /proc support in this driver.
Thanks,
Sreenivas
LSI Logic
Hi all,
On Thu, 2004-04-08 at 01:18, Bagalkote, Sreenivas wrote:
> Hello All,
>
> We are releasing the megaraid unified driver version 2.20.0.0.
> The source is available at our public ftp site:
OK, I have started to look at this driver, I have come across one
problem, which the attached patch fixes. This patch has been sent
through the list several times and has been accepted into 2.6.5.
If you don't set the module owner, then the module can be removed while
it is in use, with quite disastrous results.
A couple of other comments:
1. The Kconfig.megaraid and Makefile.2.6 files from the alpha release
are not in the beta.
2. In mraid_pci_blk_pool_destroy(), the caller "guarantees that no more
memory from the pool is in use", however, they don't have to guarantee
that pool is not null. Why? In fact, in the code it appears that this
guarantee is also made...
3. I am not sure what the local conventions on this are, but in
megaraid_alloc_cmd_packets() if the first allocation fails then we
return straight away, in all other cases we do a goto fail_alloc_cmds;
This is correct (of course) but personally I would prefer that they all
behave in a consistent fashion, and that the first failed alloc test
also did the goto. Otherwise, there is no need for the
alloc_common_mbox_f local, since whenever you go to fail_alloc_cmds
common_mbox will have been allocated (otherwise we have returned).
4. Also a consistency issue: In megaraid_mbox_mm_cmd() we handle the
deletion of a logical drive specially, by calling
megaraid_mbox_del_logdrv(), which just ensures that the drives are
"quiescent" and then calls megaraid_mbox_internal_command(), otherwise,
we just call megaraid_mbox_internal_command(). My preference, would be
for megaraid_mbox_del_logdrv() to just return when the drives are quiet
and then to call megaraid_mbox_internal_command() as per normal, makes
the flow easier to follow in my opinion. However, when we look at
megaraid_mbox_internal_done() it has the deleting of logical drive logic
inlined. I would prefer either that both functions have the special
logic inlined, or that they both have helper functions to deal with the
special case.
Anyway, hope that this helps,
Paul
kdep.h:
- mraid_scsi_host_alloc/mraid_scsi_host_dealloc should go away, just
define scsi_host_alloc/scsi_host_put wrappers for 2.4.
- mraid_scsi_set_pdev should go away, it's not needed in 2.6 at all
because scsi_add_host does all the work and for 2.4 just use
scsi_set_pci_device directly.
- all the SCP2FOO defines should go away, the 2.6 variants work for 2.4
aswell
- mraid_set_host_lock should go, just use scsi_assign_lock and define
it for 2.4.
megaraid_clib.c:
- why do you need the scb pool managment code at all? You can dynamically
allocate scbs in ->queuecommand
- can you explain the need for all the mraid_pci_blk_pool? I.e. why the
generic dma pool routines don't work for megaraid
all files:
- please avoid using scsi.h and hosts.h from drivers/scsi in favour of
the include/scsi/ headers, especially get rid of all the Scsi_Foo
typedefs