Date: Wed, 22 Nov 2000 22:01:17 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bp@butya.kz (Boris Popov) Cc: tlambert@primenet.com (Terry Lambert), marc.vanwoerkom@science-factory.com (Marc van Woerkom), freebsd-fs@FreeBSD.ORG Subject: Re: MSDOS FS and flock? Message-ID: <200011222201.PAA04375@usr07.primenet.com> In-Reply-To: <Pine.BSF.4.21.0011220717420.52344-100000@lion.butya.kz> from "Boris Popov" at Nov 22, 2000 08:13:52 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > > As it does not look esoteric, is there a reason why it is not > > > in -CURRENT? > > > > It's really the wrong approach going forward, since it means that > > the work has to be duplicated (with the possibility of error) for > > each and every VFS that is ever implemented. > > It is not a "little detail", but a normal vnode operation. It is > up to filesystem author/maintainer to decide which operations should be > implemented and which not. In this particular case there is no code > duplication other than wrapper to standard function. Of course, if this > patch going to be committed, then vop_stdadvlock() should be introduced. Well, ignoring the fact that "vop_std*" takes the decision out of the authors hands... ;^) I think the only way a vop_stdadvlock() can be introduced is if the lock list moves off of a per VFS addressed list, like that in UFS and in the MSDOSFS patch, The problem is that the only non-opaque method of creating a uniform FS object reference is the vnode. That means the list has to be hung off the vnode, for the code to be centralized. > > If you get into it in any detail, you'll see that root mounts > > aren't supported on many VFS types, either, and that there are > > similar caveats elsewhere (like the special device, named pipe, > > socket, and FIFO ownership and permissions issues I noted before). > > Indeed, but evolution of VFS is not finished :) Ugh. Software does not evolve. It is designed, and it is implemented. Designs _may_ evolve, but only if insufficient thought went into them before they were implemented (otherwise they wouldn't _need_ to evolve). When a design evolves, it should be taken as an object lesson by the original designer that they need to be more methodical and/or precise in all their future work. I view "software evolution" the way many non-US programmers view "software bugs". In many places, people don't call them "bugs", they call them "defects". The term "evolution" ducks responsibility for design, in the same way the term "bugs" ducks resonsibility for defects. People should be forced to take responsibility where they are responsible, instead of blaming "fate", "luck", "bugs", or "evolution". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011222201.PAA04375>