Re: [CFT] more kdev_t-ectomy

[viro@parcelfarce.linux.theplanet.co.uk]

[cc fixed - my apologies]

On Sun, Apr 20, 2003 at 06:00:34PM +0200, Andries Brouwer wrote:
 
> So, the interface with filesystems and with userspace has dev_t.
> For kernel-internal numbers kdev_t is better than dev_t.
> 
> Of course it may be possible to avoid kernel-internal numbers altogether.
> Sometimes that is an improvement, sometimes not. Pointers are more
> complicated than numbers - they point at something that must be allocated
> and freed and reference counted. A number is like a pointer without the
> reference counting.

Sigh...   And what, pray tell, do we do with these numbers?  That's
right, at some point(s) we use them to obtain <drumroll> pointers
to driver-supplied objects.  And that's where the lack of refcounting,
locking, etc. bites you.

Let's sort that mess out for good.  Papering over this stuff won't do
us any good and will only bring more kludgy interfaces.  $DEITY witness,
we already have enough of those.

It's not about pointers vs. numbers - we certainly have enough cases when
we really deal with the latter.  However, I'd rather have clear separation
between "32bit value presented to/by userland to identify device node"
and "value in range 0--7, representing the number of channel on a multiport
card FooLink-8X".  The latter makes perfect sense for a driver.  As does
"structure that represents given instance of FooLink-8X".  The former belongs
to interaction with userland and using it outside of that context is a kludge.
Dangerous kludge in case if it masks the aforementioned complications.
It also breeds all sorts of ugliness in the code - see the crap around
reassigning ->f_op and problems with clean implementation of revoke(2)
analogs for instance.  Or a buttload of fun induced by (completely
artificial) separation into major and minor - see the mess around UNIX98
ptys implementation, etc.

By now all uses of mk_kdev()/major()/minor()/MAJOR()/MINOR() in the drivers
are either trivially removable or represent very real problems.  And it's
not that there was a lot of them - in my current tree there's ~85 instances
of kdev_t in the source.  And only one of them (->i_rdev) is widely used -
~500 instances, most of them go away as soon as CIDR patch gets merged.
The rest is part noise, part real bugs that need to be fixed anyway (~40--80
of those).