Messages in this thread | | | Date | Tue, 11 Aug 1998 03:39:46 +0200 (MET DST) | From | Andries.Brouwer@cwi ... | Subject | Re: umount2 |
| |
> umount(path) is going the way of the dinosaurs. umount(path,flags) is > becoming the standard, and I went to the trouble to precisely copy OSF
> (thats why MNT_ not UMNT_FORCE)
OK - that is sufficient reason for MNT_FORCE.
However, I remain opposed against umount(path,flags).
Linux users use a great variety of kernels, libc versions and mount sources. Our control is not so tight as that of commercial vendors. We have to remain compatible for several years.
(Ah, my beloved 0.99p13k -rw-r--r-- 1 root root 211460 Oct 26 1993 zImage.pl13k.aeb so fast response under X...)
With both umount and umount2 present, one can write if (umount2(path, flags) == -1 && errno == ENOSYS) umount(path); so that if one has a brandnew libc and boots a stable 2.0.29 kernel, things still work. Without knowing the effect of the various bits in flags, glibc is not allowed to do the same. With only one umount prototype present one cannot even write such code.
Andries
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |