Bartlomiej Zolnierkiewicz wrote:
> You may also consider processing firestream.[ch] through indent because
> spacing is inconsistent - sometimes tabs, sometimes 8*space (it would
> be nice too have tabs everywhere).
As far as I know the tabs/spaces are exactly the way I want them.
There are tab
Hi!
Just a few hints on __init/__exit stuff...
On Wed, 22 Nov 2000, Patrick van de Lageweg wrote:
> +struct reginit_item PHY_NTC_INIT[] = {
Can be marked __initdata
> +void undocumented_pci_fix (struct pci_dev *pdev)
Can be marked __init
> +void write_phy (struct fs_dev *dev, int regnum, i
Peter Samuelson wrote:
>
> [Rogier Wolff]
> > > > +MODULE_PARM(fs_debug, "i");
> > >
> > > There's no reason to wrap these "MODULE_PARM"s inside an "#ifdef MODULE".
> > anymore in 2.4
>^^^2.2
>
> Verified in 2.2.0 (the oldest tree I hav
[Rogier Wolff]
> > > +MODULE_PARM(fs_debug, "i");
> >
> > There's no reason to wrap these "MODULE_PARM"s inside an "#ifdef MODULE".
> anymore in 2.4
^^^2.2
Verified in 2.2.0 (the oldest tree I have).
Peter
-
To unsubscribe from this lis
Mitchell Blank Jr wrote:
> * 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
For a non-hypothetical case why it makes sense to have such things in
their own header file: if you dig out some older versions of the A
Mitchell Blank Jr wrote:
> > +MODULE_PARM(fs_debug, "i");
>
> There's no reason to wrap these "MODULE_PARM"s inside an "#ifdef MODULE".
anymore in 2.4
OK.
> > +#define MIN(a,b) (((a)<(b))?(a):(b))
>
> You don't seem to ever use this definition.
H. Used to though..
On Thu, Nov 23, 2000 at 09:22:09AM +0100, Rogier Wolff wrote:
> Peter Samuelson wrote:
>
> > > +int loopback = 0;
> > > +int fs_debug = 0;
> > > +struct fs_dev *fs_boards = NULL;
>
> > Aside from the 'static' issue already mentioned, these should be left
> > uninitialized. ('gcc -fassume-bss-z
[Rogier Wolff <[EMAIL PROTECTED]>]
> However, if my code assumes that the compiler needs to initialize the
kernel
> variable one way or another, I want to put in the initialization,
> even if that means an "= 0;" which is already the default.
Well,
Peter Samuelson wrote:
> > +int loopback = 0;
> > +int fs_debug = 0;
> > +struct fs_dev *fs_boards = NULL;
> Aside from the 'static' issue already mentioned, these should be left
> uninitialized. ('gcc -fassume-bss-zero' would be nice, but then again
> in userspace it rarely matters.)
Hi Pete
[Patrick van de Lageweg]
> diff -u -r --new-file linux-2.4.0-test11.clean/drivers/atm/firestream.c
>linux-2.4.0-test11.fs50+atmrefcount/drivers/atm/firestream.c
Since you are submitting in the form of a source patch, you ought to
include the relevent bits of
drivers/atm/Makefile
drivers/at
Jes Sorensen wrote:
> 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.
Agreed,
> "Rogier" == Rogier Wolff <[EMAIL PROTECTED]> 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
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 registe
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 he
14 matches
Mail list logo
