From: Jes Sorensen <jes@linuxcare.com>
To: R.E.Wolff@bitwizard.nl (Rogier Wolff)
Cc: Mitchell Blank Jr <mitch@sfgoth.com>,
Patrick van de Lageweg <patrick@bitwizard.nl>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Rogier Wolff <wolff@bitwizard.nl>
Subject: Re: [NEW DRIVER] firestream
Date: 23 Nov 2000 00:35:42 +0100 [thread overview]
Message-ID: <d366lflgvl.fsf@lxplus015.cern.ch> (raw)
In-Reply-To: <200011222305.AAA30264@cave.bitwizard.nl>
In-Reply-To: R.E.Wolff@bitwizard.nl's message of "Thu, 23 Nov 2000 00:05:18 +0100 (MET)"
>>>>> "Rogier" == Rogier Wolff <R.E.Wolff@bitwizard.nl> writes:
Rogier> Mitchell Blank Jr wrote:
>> First, I'd like to make a couple points about driver style that I'm
>> trying to move towards with the ATM drivers. You're free to take
>> them or leave them, but I want to eventually move the tree in this
>> direction. * I don't like header files that define the registers
>> of the chip - since the header file is only included in the
>> driver's .c file you might as well just put the definitions there
>> (unless, of course, there is good reason to think that the
>> registers will be used in multiple drivers - unlikely in this case)
>> Having a seperate header file just serves to hamper searching
>> around the driver and cluttering the directory.
Rogier> I disagree vehemently.
Rogier> The header file should have 'static things' that for example a
Rogier> competing driver for the same chip could also use. The "driver
Rogier> defines" should theoretically be in a separate file. This
Rogier> rarely happens.
I guess this boils down to personal preference, I like to stick
register definitions in a seperate file as well.
I think the most important issue is when doing header files to make
sure they go with the driver code and not in include/linux unless
there really is a reason to expose them to user space. No reason to
export register definitions for Ethernet cards down there.
Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-23 0:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-22 9:32 [NEW DRIVER] firestream Patrick van de Lageweg
2000-11-22 17:23 ` Mitchell Blank Jr
2000-11-22 23:05 ` Rogier Wolff
2000-11-22 23:35 ` Jes Sorensen [this message]
2000-11-22 23:41 ` Jeff Garzik
2000-11-23 11:15 ` Rogier Wolff
2000-11-23 11:44 ` Peter Samuelson
2000-11-23 11:52 ` Rogier Wolff
2000-11-23 11:28 ` Werner Almesberger
2000-11-23 5:40 ` Peter Samuelson
2000-11-23 8:22 ` Rogier Wolff
2000-11-23 8:40 ` Peter Samuelson
2000-11-23 10:32 ` Vojtech Pavlik
2000-11-23 22:19 ` Bartlomiej Zolnierkiewicz
2000-11-23 23:43 ` Rogier Wolff
-- strict thread matches above, loose matches on Subject: below --
2000-11-29 8:45 Patrick van de Lageweg
2000-12-06 8:45 Patrick van de Lageweg
2000-12-12 15:44 Patrick van de Lageweg
2000-12-15 12:07 Patrick van de Lageweg
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=d366lflgvl.fsf@lxplus015.cern.ch \
--to=jes@linuxcare.com \
--cc=R.E.Wolff@bitwizard.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=mitch@sfgoth.com \
--cc=patrick@bitwizard.nl \
--cc=wolff@bitwizard.nl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.