Messages in this thread | | | Date | Mon, 18 Feb 2002 10:56:46 -0700 | From | Richard Gooch <> | Subject | Re: [PATCH] linux-2.417 devfs 64bit portablility issue |
| |
Carsten Otte writes: > > Hi Richard! > > >BTW: please don't send attachments. Send patches inline instead. > Sorry for sending the patch as attachment, but Notes messes > up whitespace so the patch would'nt apply if I include it directly. > > >Sorry, but I find your approach grotesque. Apart from basic warts such > >as not declaring code+data as __init, the approach of populating the > >bitfield from yet another list doesn't appeal to me. I'd much rather > >see an approach which preserved the initialisation using bitmasks. > > I do not think this patch is very nice either & it does not work at > all (the initialisation of the array is only called in error case).
Now you've confused me. Your patch seems to unconditionally initialise the bitfields at startup. I didn't see logic for restricting that initialisation to an error path.
> I find the overall thing for registering/deregistering devices & > allocating majors very inconsistent. > devfs_alloc_major and devfs_register_*dev do hold the information > about which majors are allocated in two different places without > knowing about each other (bdops field and this private bitfield). > A good solution would be if *dev_register would never return a major > being statically allocated when called with major 0. If this is the > case, I do not see what alloc_major and dealloc_major are useful > for.
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.
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.
Hey, hey! It looks like vger is sending emails again!
Regards,
Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |