Re: [CFT] more kdev_t-ectomy

[Andries.Brouwer@cwi.nl]

    From: viro@parcelfarce.linux.theplanet.co.uk
     
    > 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.

Ha, Al - did you try to understand?

Given a number, one can copy it around freely, without the need
to obtain a reference each time one copies it.
Many of these numbers are just copied around and never used.
In such a case, refcounting is a real waste of time.
But if one really wants to use the number, then a lookup is done,
and one gets a properly refcounted pointer.

So, instead of the dogmatic "numbers are bad", one might try
to estimate the cost of always refcounting versus the cost of
sometimes doing a lookup.

    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.

[this sounds like the canonical content-free diatribe]

    It's not about pointers vs. numbers - ...

[stuff I completely agree with deleted]

    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).

Yes, I tend to agree. Funny that you do not mention MKDEV - that was
the thing I worked on eliminating long ago.


Andries