On Mon, Jan 03, 2000 at 11:36:46AM +0200, warren wrote:
> Hi,everybody:
> Our company is a RAID hardware provider.Our company considers to
> public our driver source. We have some questions. Anybody can give us
> description?
I helped a company (Computone) get their multiport serial drivers
integrated into the kernel sources...
> (1)To whom our driver source are given?
There are two issues here.
First issue... Public access... Making your drivers public merely
means providing them. You don't have to give them to anyone. Making your
drivers "Open Source" is a little more than that. You make your sources
public with appropriate licensing and approval to distribute. You may want
to set up forums to discuss the drivers or provide a contact point for bug
fixes and feedback.
From your questions, I'm going to assume that is NOT what you are
really asking.
Second issue... Integrating them into the Linux kernel sources
(since this is a Linux list). You need to send a patch file with the
integrated drivers and any changes to other kernel sources to Alan Cox for
review. He may advise you to go through other people (say Dave Miller if
it were network code) but I would definitely start with Alan. He may
(probably) send you back a reply with some advise on how the driver should
operate or be modified (we had to split our driver into two pieces to
avoid a bloat of initialization microcode).
> (2)If a distributor try to distribute his collection, who will make
> sure the driver works for our hardware?
The users? :-) Seriously, someone with that hardware out in netland.
In doing our drivers, we made sure we had people (myself included) with those
boards in services. Then we make sure each kernel rev gets build and running
on those boards. You will proabably want at least one staff person familiar
with the setup and testing kernel revs and keep a test setup working in your
lab. You will probably want one or more persons listed as the driver
maintainers for low level problems pretaining to your board.
> (3)If users have encountered the bugs in the driver, who will fix
> it? And how does the distributor update his collection?
Depends... If it's a kernel integration issue, the kernel maintainers
will fix it. Consider this a layered process. If it's some change that
gets made to the kernel internals, the people who are managing that change
are going to update your drivers as well. I had this happen several times
with the Computone driver in the 2.3 series already. I didn't have to do
a thing. If it's not kernel integration, then the driver maintainers have
to take a hand. I'm listed along with an individual at Computone as the
offical maintainers of that driver. I manage certain aspects of the driver
and Doug manages others. If it's a problem in the proc interface or some
other kernel interface issue, it's my baby. If it's the board microcode
or the low level hardware interfaces, it's Doug's baby. If it's something
in between, it's a jump ball. We have a mailing list and web pages set up
to take feedback and patches from users. If someone finds a bug, they
generally suggest ways to fix it. We decide how it "should be" fixed and
submit the patches to Alan.
> If i post to the wrong place, i am sorry for this.
> Best Regards
> Warren
Disclaimer... I don't work for Computone. I just happen to use
their boards on SCO Unix and wanted them on Linux.
Mike
--
Michael H. Warfield | (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
