Messages in this thread | | | Subject | Re: [PATCH] linux-2.417 devfs 64bit portablility issue | From | "Carsten Otte" <> | Date | Thu, 21 Feb 2002 15:48:34 +0100 |
| |
Richard Gooch writes: >Except that devfs_register_???dev() (which are in fact minor >variations on the register_???dev() calls) *do not* avoid assigned >majors. That is why I wrote devfs_alloc_major() in the first place. To me, the disadvantage of this soloution is that if a device driver has called devfs_register_blkdev with major 0 (automatic allocation) and another device driver calls devfs_alloc_major, the same major number may be assigned twice. Same situation is vice versa (major has been allocated, devfs_register_blkdev with major 0 gives the same major to a different driver).
>And while I do think that register_???dev() should in fact do just >what devfs_alloc_major() does, that's not a battle I care to fight. By >writing devfs_alloc_major(), this functionality is optional, and I can >avoid a whole pile of stupid flaming. I reworked my initial patch in order to - avoid setting up the array on initialisation (since you dislike this) - have a portable soloution that works on any arch - avoid assigning staticaly allocated majors with any devfs_* functions - avoid assigning the same major twice with devfs_* functions
Please do have a look at this patch (sorry, attached again) and let me know what you think of including this solution.
w/kind regards Carsten Otte (See attached file: linux-2.4.17-devfs_fixup.diff)[unhandled content-type:application/octet-stream] | |