Hi Robert, * Robert Watson <rwat...@freebsd.org> wrote: > The underlying change seems fine, especially in -CURRENT, but I'm > confused by the paragraph here on alignment and safety. What do you > mean by safe, and does it matter?
With safe I mean that all useful members still begin at the same offset
within the structure. I'm not sure whether it matters at all, because I
can imagine d_devs could be moved around without having any effect, but
I'm not going to make any predictions on that.
> From a casual glance (perhaps mistaken), it looks like this changes
> the KBI, so all modules declaring struct cdevsw will need to be
> rebuilt.
It shouldn't, right?
- uid_t d_uid;
- gid_t d_gid;
- mode_t d_mode;
- const char *d_kind;
+
+ int32_t d_spare0[3];
+ void *d_spare1[3];
/* These fields should not be messed with by drivers */
- LIST_ENTRY(cdevsw) d_list;
d_uid, d_gid and d_mode is equal to:
int32_t d_uid;
int32_t d_gid;
int16_t d_mode;
Because d_kind is a pointer, there will be a hole in the structure of at
least 2 bytes (maybe even 6), which means we can safely extend d_mode to
32 bits as well. I could have decided to leave it at uint16_t, but that
would only obfuscate it even more when we would try to reclaim some
space there.
d_list is just two pointers, so I merged it with d_kind into an array of
three pointers.
--
Ed Schouten <e...@80386.nl>
WWW: http://80386.nl/
pgp5dORJFjGWu.pgp
Description: PGP signature
