Messages in this thread | | | From | Andries.Brouwer@cwi ... | Date | Sun, 20 Apr 2003 23:17:17 +0200 (MEST) | Subject | Re: [CFT] more kdev_t-ectomy |
| |
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
- 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/
| |