[lkml]   [2002]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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!


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.028 / U:6.744 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site