Why are the arg[1234]-fields in struct iot_entry "int" ?
Those fields are sometimes used to store pointers in it
and so they force fancy casts on 64-Bit platforms which makes
the game sometimes a bit and sometimes total useless
(byte-order dependent).
Example: fs/buffer.c
IO_trace (IO_wait_on_buffer, bh->b_rdev, bh->b_rsector,
(int)(__builtin_return_address(0)),0);
Yes I know that this won't cause real trouble and I also know that
the trace is unusable on all non intel platforms (because timestamp = 0),
but linux/fs is IMHO arch-independent and so I thread this as non-critical
- but worth to mention - design bug.
It would be cool if there would be at least a warning about "CONFIG_FS_CODA"
which is simply not 64-Bit clean without additional patches.
In fact I would exclude it for some ARCH's in fs/Config.in at all.
Idea behind this: It can't work in the current form on AXP so a dummy-user
should not be able to select it. If a patch make this work it should remove
the showstopper in fs/Config.in.
These things are simple things that make IMHO sense for normal users
and it's easy to apply them without breaking anything else.
It's a modified variant of Ted's "customer service" thoughts.
The CODA stuff is just an example. Many (ex.: SCSI) drivers should
be ARCH-dependent flagged out if they are known _not_ to work or at least
there should be a comment in Documentation/Configure.help or at least
somewhere in the Documentation tree.
Just some thoughts about things that hit me when supporting customers
on the phone.
--
ciao -
Stefan
Stefan Traby phone: +43-3133-6107-2
Mitterlasznitzstr. 13 fax: +43-3133-6107-9
8302 Nestelbach mailto://stefan@sime.com
Austria
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/