Messages in this thread | | | Date | Sat, 30 Jan 1999 03:57:01 +0100 | From | Stefan Traby <> | Subject | Be arch friendly, struct iot_entry and other things |
| |
Hi !
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/
| |