Messages in this thread |  | | Date | Wed, 06 Sep 2000 20:40:08 +0200 | From | Martin Dalecki <> |
| |
Alexander Viro wrote: > > On Wed, 6 Sep 2000, Martin Dalecki wrote: > > > <IRONY ON> > > So may I just suggest to repleace the usage of cpp at all with something > > more > > suitable for the task at hand and with a much more regular/stringent > > syntax > > better fitting into the syntax of the pure C language like m4 for > > example? > > </IRONY OFF> > > No. Still "better tools" variant. Check blk_dev_init() and tell me how do > you like the end of this function (drivers/block/ll_rw_blk.c). BTW, check
Yes you are right here I don't like this particular piece of code in esp since:
1. The macro hackery may very well be replaced with "vanishing macros" at the declaration level.
2. This is basically an fully unrolled loop of calls into a function pointer table.
3. It's making the corresponding driver code non self contained.
> how many of these CONFIG_... are needed anywhere on C level. Hint: see > module_init macro.
Yes I like the introduction of the ld hackere there very much: It's basically solving the problems 1. 2. and 3. by doing the proper thing ;-) i.e. provide an statically initialized list of addresses and call them out of a loop.
> > The main problem with the CONFIG_ blah's isn't either the syntax nor > > they current usage - the problem is inherent to the simple fact > > that the number of possible combinations is of a very high order due > > to simple combinatorics. > > It's not a fact, it's a problem... It doesn't _have_ to be very high > order on cc level. ld - sure, but that's much simpler to deal with.
But in some cases the driver api in linux are not quite supportiv for this. Please have a look at the strattegy routine (please allow me to use the proper UNIX terminology here ;-) declaration hackery inside of ide.h, oh sorry it gote moved and I can't quite find it again... ;-) - 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/
|  |