>> = Adam Richter
> = Tim Waugh
>> -extern ssize_t parport_device_id (int devnum, char *buffer, size_t len);
>> +extern ssize_t parport_get_id (int devnum, char **buf_out);
>This is just unnecessary, as well as changing the documented interface
>(Documentation/DocBook). This is worse than the autoprobe thing!
The name change is because the MODULE_DEVICE_TABLE macro
in include/linux/module.h requires that if the type of table is
called "parport", then the ID structure must be named parport_device_id
and having a procedure of the same name makes it hard to grep for
either of them and would break a module that uses C++.
Allocating the string on the fly greatly simplifies the
code in a couple of places and also allows it to handle strings
longer than the size that you happened to preallocate.
I have updated all of the places in the kernel that call
these routines. Are there any currently existing modules outside
of the kernel that use this interface and do not want to switch?
>Please stop making gratuitous changes to interfaces, or the whole
>thing will have to wait until 2.5.x.
>> -extern int parport_find_device (const char *mfg, const char *mdl, int from);
>> -extern int parport_find_class (parport_device_class cls, int from);
>And again we have an interface change.
Nothing in the stock kernel calls these routines anymore.
Again, are there any modules outside of the kernel that actually
use this interface and would not want to change?
Putting back those routines means either putting back all of
that unnecessary parsing code and the old data structures or
writing new versions of these routines (which would probably be
easier). It's not that much work, but it's probably more work
than updating, say, two or three modules under development outside
the kernel.
>Adam, to do this now that we are in a stable branch, we have to only
>_add_ bits.
That has not been the case in the 2.2 branch (for
example, 2.2.18 deleted the exported symbols machine_type, outswb,
inswb, __arch_strlen_user, armidlist, armidindex, msgqueue_getnextmsg,
msgqueue_peeknextmsg, loops_per_sec and rpc_do_call). Historically,
Linus has been pretty sympathetic to code cleanups even at the cost
of some interface changes, even in a stable branch (although not as
much). Has Linus announced a new policy for 2.4?
I am willing to write drivers/parport/parport_bloat.c
(so that it will compile as a separate module that modprobe will
automatically load if needed, and otherwise will not waste unswappable
kernel memory), which would contain the legacy routines if you insist.
I believe that they will never be called from any module that anyone
ever ships.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Thu Jan 18 2001 - 19:29:21 EST