Re: [PATCH] 2.5.31 driverfs: patch for your consideration

Patrick Mochel (mochel@osdl.org)
Mon, 19 Aug 2002 11:10:58 -0700 (PDT)


> I downloaded my patches through the mailing list and applied them:
>
> bash-2.05a$ cat ./driver.patch | patch -p1 -l -d linux
> patching file drivers/base/interface.c
> bash-2.05a$ cat ./driver2.patch | patch -p1 -l -d linux
> patching file drivers/base/base.h
> patching file drivers/base/core.c
> patching file drivers/base/interface.c
>
> It applies cleanly but . . .

patch -l does not imply cleanly. That will ignore the whitespace munging
that your MUA is doing.

> You're right the tabs are gone although when I applied my originals they
> weren't. I hate netscape navigator. I gzipped them so netscape can't
> mess them up. In the meantime I'm going to download mutt. Thanks for
> your help. Let me know if the patch works this time. Also after
> looking at the interface code I realized that not just my code used
> sprintf. Do you think they should all use snprintf instead or is the
> probability of a driver attribute exceeding the one page buffer size so
> low that it doesn't matter?

They should use snprintf. Thanks for pointing that out.

> Also I was wondering if you think resource management variables (irq,
> io, dma, etc) should live in the device structure like power management
> variables do? Global resource management seams interesting to me,
> although there already is a proc interface that does list resources, I'm
> wondering if the driver model is a good place to put such an interface?

Yes. We talked about doing that from the very beginning, and were going to
see how things worked out. There was some dicussion about this at OLS,
too. But, I'm not sure it's ready for it yet.

What would be nice would be some way to cleanly represent conditional
attributes of devices, like resource and power management. I think I
almost have something with the device interface stuff, but I fear it's a
fine line to cross over into Abstraction Hell...

</tangent>

-pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/