Re: HEADS UP Reviewers. VFS changes to be committed.
In message [EMAIL PROTECTED], Alfred P erlstein writes: On Fri, 27 Aug 1999, Poul-Henning Kamp wrote: Uhm, have any of you actually ever looked at src/sys/kern/vnode_if.src ? I can't really tell if you are commenting on the diffs I provided or if you are commmenting on the comments I have recieved, or both. Mostly the comments actually I'm overloaded at the moment, so I have not been able to find time to sit down and thing through this one, sorry... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
In message pine.bsf.4.05.9908282023450.6392-100...@fw.wintelcom.net, Alfred P erlstein writes: On Fri, 27 Aug 1999, Poul-Henning Kamp wrote: Uhm, have any of you actually ever looked at src/sys/kern/vnode_if.src ? I can't really tell if you are commenting on the diffs I provided or if you are commmenting on the comments I have recieved, or both. Mostly the comments actually I'm overloaded at the moment, so I have not been able to find time to sit down and thing through this one, sorry... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Fri, 27 Aug 1999, Poul-Henning Kamp wrote: Uhm, have any of you actually ever looked at src/sys/kern/vnode_if.src ? I can't really tell if you are commenting on the diffs I provided or if you are commmenting on the comments I have recieved, or both. Either way, could you elaborate a bit? I was hoping for your input on this issue. thank you, -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] Poul-Henning In message [EMAIL PROTECTED], Erez Zadok write s: In message [EMAIL PROTECTED], Matthew Dillon writes: [...] I would ask two things though: * First, please add comprehensive /* */ comments in front of each vfsnop_*() procedure explaining what it does, why it returns what it returns, locking requirements (if any) on entry, and side effects on return. This is just for readability. Do the same for all the procedures you are adding, in fact. Moreover, I would strongly recommend xplicitly documenting the following: - which function args are in-args and which are out-args? - does the function takes any allocated memory that it is expected to free? - is the function expected to allocate any memory objects that have to be freed elsewhere? - does the function increase or decrease any reference counts of any objects? Is it expected to? These and other requirements are essentially the "interface" between the VFS and lower-level file systems. Figuring out this stuff on every OS and OS revision (esp. when the VFS changes so often---linux) was the longest most frustrating task I faced when writing my Wrapfs stackable f/s module for solaris, freebsd, and linux. I wish documentation had been in place. * I think you can safely commit any elements that are not used by existing builds since they are not likely to impact existing builds operationally. Then see what you have left over. If it is not significant, commit that to. If it is significant, do more comprehensive testing on what you have left over (i.e. that impacts existing builds) and ask for another review after testing, before committing it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Fri, 27 Aug 1999, Poul-Henning Kamp wrote: Uhm, have any of you actually ever looked at src/sys/kern/vnode_if.src ? I can't really tell if you are commenting on the diffs I provided or if you are commmenting on the comments I have recieved, or both. Either way, could you elaborate a bit? I was hoping for your input on this issue. thank you, -Alfred Perlstein - [bri...@rush.net|alf...@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bri...@wintelcom.net] Poul-Henning In message 199908272018.qaa22...@shekel.mcl.cs.columbia.edu, Erez Zadok write s: In message 199908261727.kaa23...@apollo.backplane.com, Matthew Dillon writes: [...] I would ask two things though: * First, please add comprehensive /* */ comments in front of each vfsnop_*() procedure explaining what it does, why it returns what it returns, locking requirements (if any) on entry, and side effects on return. This is just for readability. Do the same for all the procedures you are adding, in fact. Moreover, I would strongly recommend xplicitly documenting the following: - which function args are in-args and which are out-args? - does the function takes any allocated memory that it is expected to free? - is the function expected to allocate any memory objects that have to be freed elsewhere? - does the function increase or decrease any reference counts of any objects? Is it expected to? These and other requirements are essentially the interface between the VFS and lower-level file systems. Figuring out this stuff on every OS and OS revision (esp. when the VFS changes so often---linux) was the longest most frustrating task I faced when writing my Wrapfs stackable f/s module for solaris, freebsd, and linux. I wish documentation had been in place. * I think you can safely commit any elements that are not used by existing builds since they are not likely to impact existing builds operationally. Then see what you have left over. If it is not significant, commit that to. If it is significant, do more comprehensive testing on what you have left over (i.e. that impacts existing builds) and ask for another review after testing, before committing it. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
In message [EMAIL PROTECTED], Matthew Dillon writes: [...] I would ask two things though: * First, please add comprehensive /* */ comments in front of each vfsnop_*() procedure explaining what it does, why it returns what it returns, locking requirements (if any) on entry, and side effects on return. This is just for readability. Do the same for all the procedures you are adding, in fact. Moreover, I would strongly recommend xplicitly documenting the following: - which function args are in-args and which are out-args? - does the function takes any allocated memory that it is expected to free? - is the function expected to allocate any memory objects that have to be freed elsewhere? - does the function increase or decrease any reference counts of any objects? Is it expected to? These and other requirements are essentially the "interface" between the VFS and lower-level file systems. Figuring out this stuff on every OS and OS revision (esp. when the VFS changes so often---linux) was the longest most frustrating task I faced when writing my Wrapfs stackable f/s module for solaris, freebsd, and linux. I wish documentation had been in place. * I think you can safely commit any elements that are not used by existing builds since they are not likely to impact existing builds operationally. Then see what you have left over. If it is not significant, commit that to. If it is significant, do more comprehensive testing on what you have left over (i.e. that impacts existing builds) and ask for another review after testing, before committing it. Erez. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
Uhm, have any of you actually ever looked at src/sys/kern/vnode_if.src ? Poul-Henning In message [EMAIL PROTECTED], Erez Zadok write s: In message [EMAIL PROTECTED], Matthew Dillon writes: [...] I would ask two things though: * First, please add comprehensive /* */ comments in front of each vfsnop_*() procedure explaining what it does, why it returns what it returns, locking requirements (if any) on entry, and side effects on return. This is just for readability. Do the same for all the procedures you are adding, in fact. Moreover, I would strongly recommend xplicitly documenting the following: - which function args are in-args and which are out-args? - does the function takes any allocated memory that it is expected to free? - is the function expected to allocate any memory objects that have to be freed elsewhere? - does the function increase or decrease any reference counts of any objects? Is it expected to? These and other requirements are essentially the "interface" between the VFS and lower-level file systems. Figuring out this stuff on every OS and OS revision (esp. when the VFS changes so often---linux) was the longest most frustrating task I faced when writing my Wrapfs stackable f/s module for solaris, freebsd, and linux. I wish documentation had been in place. * I think you can safely commit any elements that are not used by existing builds since they are not likely to impact existing builds operationally. Then see what you have left over. If it is not significant, commit that to. If it is significant, do more comprehensive testing on what you have left over (i.e. that impacts existing builds) and ask for another review after testing, before committing it. Erez. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-fs" in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
In message 199908261727.kaa23...@apollo.backplane.com, Matthew Dillon writes: [...] I would ask two things though: * First, please add comprehensive /* */ comments in front of each vfsnop_*() procedure explaining what it does, why it returns what it returns, locking requirements (if any) on entry, and side effects on return. This is just for readability. Do the same for all the procedures you are adding, in fact. Moreover, I would strongly recommend xplicitly documenting the following: - which function args are in-args and which are out-args? - does the function takes any allocated memory that it is expected to free? - is the function expected to allocate any memory objects that have to be freed elsewhere? - does the function increase or decrease any reference counts of any objects? Is it expected to? These and other requirements are essentially the interface between the VFS and lower-level file systems. Figuring out this stuff on every OS and OS revision (esp. when the VFS changes so often---linux) was the longest most frustrating task I faced when writing my Wrapfs stackable f/s module for solaris, freebsd, and linux. I wish documentation had been in place. * I think you can safely commit any elements that are not used by existing builds since they are not likely to impact existing builds operationally. Then see what you have left over. If it is not significant, commit that to. If it is significant, do more comprehensive testing on what you have left over (i.e. that impacts existing builds) and ask for another review after testing, before committing it. Erez. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
Uhm, have any of you actually ever looked at src/sys/kern/vnode_if.src ? Poul-Henning In message 199908272018.qaa22...@shekel.mcl.cs.columbia.edu, Erez Zadok write s: In message 199908261727.kaa23...@apollo.backplane.com, Matthew Dillon writes: [...] I would ask two things though: * First, please add comprehensive /* */ comments in front of each vfsnop_*() procedure explaining what it does, why it returns what it returns, locking requirements (if any) on entry, and side effects on return. This is just for readability. Do the same for all the procedures you are adding, in fact. Moreover, I would strongly recommend xplicitly documenting the following: - which function args are in-args and which are out-args? - does the function takes any allocated memory that it is expected to free? - is the function expected to allocate any memory objects that have to be freed elsewhere? - does the function increase or decrease any reference counts of any objects? Is it expected to? These and other requirements are essentially the interface between the VFS and lower-level file systems. Figuring out this stuff on every OS and OS revision (esp. when the VFS changes so often---linux) was the longest most frustrating task I faced when writing my Wrapfs stackable f/s module for solaris, freebsd, and linux. I wish documentation had been in place. * I think you can safely commit any elements that are not used by existing builds since they are not likely to impact existing builds operationally. Then see what you have left over. If it is not significant, commit that to. If it is significant, do more comprehensive testing on what you have left over (i.e. that impacts existing builds) and ask for another review after testing, before committing it. Erez. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-fs in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Thu, 26 Aug 1999 08:28:29 GMT, Alfred Perlstein wrote: Am I to take it that silence is accpetance? I'll be committing this to -current tonight or tomorrow unless I get feedback. Recent discussions with bde and eivind indicate that at least some of the code you're about to touch has one or more maintainers. Kirk McKusick is probably one of them. Make sure you contact the maintainers directly before smacking their code. Also, I'd suggest that it's a bad idea to say "if I get no feedback before tonight, I'm committing". I think this applies even if it's not the first time you've asked for review. Basically, timezones and stuff make for a situation where such an e-mail is useless for many of your readers. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Thu, 26 Aug 1999, Sheldon Hearn wrote: Also, I'd suggest that it's a bad idea to say "if I get no feedback before tonight, I'm committing". I think this applies even if it's not the first time you've asked for review. Basically, timezones and stuff make for a situation where such an e-mail is useless for many of your readers. This would be post #3 of the same code and changes that no-one has reponded to. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
Just a few comments... 2) The casting of VFS ops to eopnotsupp() has been removed and vfs_nop*() functions have been put into kern/vfs_default.c This makes it more clear that certain VFS-ops are giving default behavior, either returning automatic success or returning EOPNOTSUPP. I like the idea. (However, I think that the functions returning failure should not be called NOPs.) Why does VFS_CHECKEXP take a vnode and not a mount point? Hopefully in the future a filesystem will be able to more restrictively export its files, this will help facilitate that. IMO, if it take a vnode, it should be VOP_CHECKEXP, not VFS_CHECKEXP. Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Thu, 26 Aug 1999 11:45:47 -0400, Bill Fumerola wrote: This would be post #3 of the same code and changes that no-one has reponded to. I hear you, and I was aware of that when I made my comments. Basically, it's a waste of time saying such a thing, so either be prepared to wait longer, or don't say it. :-) Feelings, nothing more than feelings... Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
:I've posted 2 times asking for someone to review these diffs: : :http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff : :Am I to take it that silence is accpetance? I'll be committing this :to -current tonight or tomorrow unless I get feedback. : :See attached email for details. : :thank you, :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] :Wintelcom systems administrator and programmer : - http://www.wintelcom.net/ [[EMAIL PROTECTED]] : :3) fh(open|stat|statfs) have been haphazardly implemented, meaning I : won't be able to test them until tonight. : :Testers? Critics? Comments? please? : :If you're wondering why/what I'm doing, it's the kernel support :for a lockd that I'm working on, as well as a cleanup I thought :would make it easier to understand our filesystem code. : :I'm sure some people will be wondering: :Why does VFS_CHECKEXP take a vnode and not a mount point? :.. :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] I've done a quick once-over of your patch. From the point of view of the work I'm doing and the work Kirk will be doing later on, I do not think the patch will cause any problems since you are adding new VOPs for the most part rather then modifying (too many) existing VOPs. Most of the work that Kirk and I will be doing will concentrate on namei, locking, and I/O, which you mostly avoid in your patch. In general I like the idea of implementing reasonable defaults. I would ask two things though: * First, please add comprehensive /* */ comments in front of each vfsnop_*() procedure explaining what it does, why it returns what it returns, locking requirements (if any) on entry, and side effects on return. This is just for readability. Do the same for all the procedures you are adding, in fact. * I think you can safely commit any elements that are not used by existing builds since they are not likely to impact existing builds operationally. Then see what you have left over. If it is not significant, commit that to. If it is significant, do more comprehensive testing on what you have left over (i.e. that impacts existing builds) and ask for another review after testing, before committing it. A working lock daemon would be totally awesome! The fh*() routines you are adding are roughly what you (and we) need to make progress in this area! -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Thu, 26 Aug 1999, Dmitrij Tejblum wrote: Just a few comments... 2) The casting of VFS ops to eopnotsupp() has been removed and vfs_nop*() functions have been put into kern/vfs_default.c This makes it more clear that certain VFS-ops are giving default behavior, either returning automatic success or returning EOPNOTSUPP. I like the idea. (However, I think that the functions returning failure should not be called NOPs.) What do you suggest? I'm flexible about this. Why does VFS_CHECKEXP take a vnode and not a mount point? Hopefully in the future a filesystem will be able to more restrictively export its files, this will help facilitate that. IMO, if it take a vnode, it should be VOP_CHECKEXP, not VFS_CHECKEXP. #define VFS_VPTOFH(VP, FIDP) (*(VP)-v_mount-mnt_op-vfs_vptofh)(VP, FIDP) #define VFS_CHECKEXP(VP, NAM, EXFLG, CRED) \ (*(VP)-v_mount-mnt_op-vfs_checkexp)(VP, NAM, EXFLG, CRED) since i'm doing a lot of grunt work and would like to get it in, in a single commit what do you think of doing the same with VPTOFH? My only concern is that export-ability is more a VFS function than a vnode operation, even if the argument is a vnode. I'm not opposed to the work, it's just that there already exists a VFS_op that takes a vnode argument and my statement above about it being a function of the VFS. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Thu, 26 Aug 1999, Matthew Dillon wrote: :I've posted 2 times asking for someone to review these diffs: : :http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff : :Am I to take it that silence is accpetance? I'll be committing this :to -current tonight or tomorrow unless I get feedback. : :See attached email for details. : :thank you, :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] :Wintelcom systems administrator and programmer : - http://www.wintelcom.net/ [[EMAIL PROTECTED]] : :3) fh(open|stat|statfs) have been haphazardly implemented, meaning I : won't be able to test them until tonight. : :Testers? Critics? Comments? please? : :If you're wondering why/what I'm doing, it's the kernel support :for a lockd that I'm working on, as well as a cleanup I thought :would make it easier to understand our filesystem code. : :I'm sure some people will be wondering: :Why does VFS_CHECKEXP take a vnode and not a mount point? :.. :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] I've done a quick once-over of your patch. From the point of view of the work I'm doing and the work Kirk will be doing later on, I do not think the patch will cause any problems since you are adding new VOPs for the most part rather then modifying (too many) existing VOPs. VFS, not VOP. Most of the work that Kirk and I will be doing will concentrate on namei, locking, and I/O, which you mostly avoid in your patch. In general I like the idea of implementing reasonable defaults. I would ask two things though: * First, please add comprehensive /* */ comments in front of each vfsnop_*() procedure explaining what it does, why it returns what it returns, locking requirements (if any) on entry, and side effects on return. This is just for readability. Do the same for all the procedures you are adding, in fact. The code isn't VOPs, it's VFS_ops, since they do nothing and don't block there really aren't any pre-requisites for calling them. VFS_CHECKEXP inherits the requirements of the old VFS_FHTOVP. However, dt suggested I make VFS_CHECKEXP a VOP instead of VFS, my only gripe is that exportability is determined by the filesystem, _then_ the vnode, making it more of a VFS op imo. * I think you can safely commit any elements that are not used by existing builds since they are not likely to impact existing builds operationally. Then see what you have left over. If it is not significant, commit that to. If it is significant, do more comprehensive testing on what you have left over (i.e. that impacts existing builds) and ask for another review after testing, before committing it. I'm totally lost here, can you re-phrase this? As far as the work done here, it's mostly a clean-up, no functional changes with the exception of the addition of the fh* syscalls. I guess you could call the VFS_CHECKEXP a functional change, but it's more of a re-org /pointy hair speak :) A working lock daemon would be totally awesome! The fh*() routines you are adding are roughly what you (and we) need to make progress in this area! Yes, i'd really like to get this off the ground. :) Btw, are you planning on attending any BAFUG coming up? I'd love to hear some of the preliminary stuff you are proposing for the filesystem. Thank you for your time, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
However, dt suggested I make VFS_CHECKEXP a VOP instead of VFS, my only gripe is that exportability is determined by the filesystem, _then_ the vnode, making it more of a VFS op imo. I think dt is right here; the issue is that the operation is performed on a vnode, not on a filesystem, and thus it's a VOP not a VFSOP. Btw, are you planning on attending any BAFUG coming up? I'd love to hear some of the preliminary stuff you are proposing for the filesystem. There's one tonight in Berkeley. Be there. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
: : I've done a quick once-over of your patch. From the point of view of : the work I'm doing and the work Kirk will be doing later on, I do : not think the patch will cause any problems since you are adding new : VOPs for the most part rather then modifying (too many) existing VOPs. : :VFS, not VOP. Oops, sorry. I meant VFS. Same comments apply :-) Despite all the arguing on the lists about VFS defaults and related issues, nobody is doing or contemplating any actual work in this area (i.e. VFS vs VOP) except for you, so you are not conflicting with anyone. :vfsnop_*() procedure explaining what it does, why it returns what :it returns, locking requirements (if any) on entry, and side effects :on return. This is just for readability. : :Do the same for all the procedures you are adding, in fact. : :The code isn't VOPs, it's VFS_ops, since they do nothing and don't :block there really aren't any pre-requisites for calling them. Sounds like a good comment! You and I may understand the code just fine, but the comments will help other developers. :VFS_CHECKEXP inherits the requirements of the old VFS_FHTOVP. : :However, dt suggested I make VFS_CHECKEXP a VOP instead of VFS, my only :gripe is that exportability is determined by the filesystem, _then_ the :vnode, making it more of a VFS op imo. Since you are the only one using it for the moment, do what you feel is best. Once you've begun implementing code that uses the new VFSops the appropriate place will become obvious and you can make the change (if any) then. :that to. If it is significant, do more comprehensive testing on :what you have left over (i.e. that impacts existing builds) and :ask for another review after testing, before committing it. : :I'm totally lost here, can you re-phrase this? : :As far as the work done here, it's mostly a clean-up, no functional changes :with the exception of the addition of the fh* syscalls. I guess you :could call the VFS_CHECKEXP a functional change, but it's more of a :re-org /pointy hair speak :) For example, when I add certain functionality that was turned on by a sysctl (which defaults to off), I feel that it is 'safe' to commit it into the tree even though it may not have been tested comprehensively, because nobody else is going to touch that code operationally. I make the distinction between new code that isn't exercised by systems built by other people and new code which is. The new code that isn't exercised does not need the level of testing prior to commit that code which is exercised by the masses needs. That's all. It's a rule of thumb of mine. : A working lock daemon would be totally awesome! The fh*() routines : you are adding are roughly what you (and we) need to make progress in : this area! : :Yes, i'd really like to get this off the ground. :) : :Btw, are you planning on attending any BAFUG coming up? I'd love to hear :some of the preliminary stuff you are proposing for the filesystem. : :Thank you for your time, :-Alfred I don't know re: the BAFUG meeting. I might not be in town. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Thu, 26 Aug 1999 08:28:29 GMT, Alfred Perlstein wrote: Am I to take it that silence is accpetance? I'll be committing this to -current tonight or tomorrow unless I get feedback. Recent discussions with bde and eivind indicate that at least some of the code you're about to touch has one or more maintainers. Kirk McKusick is probably one of them. Make sure you contact the maintainers directly before smacking their code. Also, I'd suggest that it's a bad idea to say if I get no feedback before tonight, I'm committing. I think this applies even if it's not the first time you've asked for review. Basically, timezones and stuff make for a situation where such an e-mail is useless for many of your readers. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Thu, 26 Aug 1999, Sheldon Hearn wrote: Also, I'd suggest that it's a bad idea to say if I get no feedback before tonight, I'm committing. I think this applies even if it's not the first time you've asked for review. Basically, timezones and stuff make for a situation where such an e-mail is useless for many of your readers. This would be post #3 of the same code and changes that no-one has reponded to. -- - bill fumerola - bi...@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfume...@computerhorizons.com - bi...@freebsd.org - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
Just a few comments... 2) The casting of VFS ops to eopnotsupp() has been removed and vfs_nop*() functions have been put into kern/vfs_default.c This makes it more clear that certain VFS-ops are giving default behavior, either returning automatic success or returning EOPNOTSUPP. I like the idea. (However, I think that the functions returning failure should not be called NOPs.) Why does VFS_CHECKEXP take a vnode and not a mount point? Hopefully in the future a filesystem will be able to more restrictively export its files, this will help facilitate that. IMO, if it take a vnode, it should be VOP_CHECKEXP, not VFS_CHECKEXP. Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Thu, 26 Aug 1999 11:45:47 -0400, Bill Fumerola wrote: This would be post #3 of the same code and changes that no-one has reponded to. I hear you, and I was aware of that when I made my comments. Basically, it's a waste of time saying such a thing, so either be prepared to wait longer, or don't say it. :-) Feelings, nothing more than feelings... Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
:I've posted 2 times asking for someone to review these diffs: : :http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff : :Am I to take it that silence is accpetance? I'll be committing this :to -current tonight or tomorrow unless I get feedback. : :See attached email for details. : :thank you, :-Alfred Perlstein - [bri...@rush.net|alf...@freebsd.org] :Wintelcom systems administrator and programmer : - http://www.wintelcom.net/ [bri...@wintelcom.net] : :3) fh(open|stat|statfs) have been haphazardly implemented, meaning I : won't be able to test them until tonight. : :Testers? Critics? Comments? please? : :If you're wondering why/what I'm doing, it's the kernel support :for a lockd that I'm working on, as well as a cleanup I thought :would make it easier to understand our filesystem code. : :I'm sure some people will be wondering: :Why does VFS_CHECKEXP take a vnode and not a mount point? :.. :-Alfred Perlstein - [bri...@rush.net|alf...@freebsd.org] I've done a quick once-over of your patch. From the point of view of the work I'm doing and the work Kirk will be doing later on, I do not think the patch will cause any problems since you are adding new VOPs for the most part rather then modifying (too many) existing VOPs. Most of the work that Kirk and I will be doing will concentrate on namei, locking, and I/O, which you mostly avoid in your patch. In general I like the idea of implementing reasonable defaults. I would ask two things though: * First, please add comprehensive /* */ comments in front of each vfsnop_*() procedure explaining what it does, why it returns what it returns, locking requirements (if any) on entry, and side effects on return. This is just for readability. Do the same for all the procedures you are adding, in fact. * I think you can safely commit any elements that are not used by existing builds since they are not likely to impact existing builds operationally. Then see what you have left over. If it is not significant, commit that to. If it is significant, do more comprehensive testing on what you have left over (i.e. that impacts existing builds) and ask for another review after testing, before committing it. A working lock daemon would be totally awesome! The fh*() routines you are adding are roughly what you (and we) need to make progress in this area! -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Thu, 26 Aug 1999, Dmitrij Tejblum wrote: Just a few comments... 2) The casting of VFS ops to eopnotsupp() has been removed and vfs_nop*() functions have been put into kern/vfs_default.c This makes it more clear that certain VFS-ops are giving default behavior, either returning automatic success or returning EOPNOTSUPP. I like the idea. (However, I think that the functions returning failure should not be called NOPs.) What do you suggest? I'm flexible about this. Why does VFS_CHECKEXP take a vnode and not a mount point? Hopefully in the future a filesystem will be able to more restrictively export its files, this will help facilitate that. IMO, if it take a vnode, it should be VOP_CHECKEXP, not VFS_CHECKEXP. #define VFS_VPTOFH(VP, FIDP) (*(VP)-v_mount-mnt_op-vfs_vptofh)(VP, FIDP) #define VFS_CHECKEXP(VP, NAM, EXFLG, CRED) \ (*(VP)-v_mount-mnt_op-vfs_checkexp)(VP, NAM, EXFLG, CRED) since i'm doing a lot of grunt work and would like to get it in, in a single commit what do you think of doing the same with VPTOFH? My only concern is that export-ability is more a VFS function than a vnode operation, even if the argument is a vnode. I'm not opposed to the work, it's just that there already exists a VFS_op that takes a vnode argument and my statement above about it being a function of the VFS. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
On Thu, 26 Aug 1999, Matthew Dillon wrote: :I've posted 2 times asking for someone to review these diffs: : :http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff : :Am I to take it that silence is accpetance? I'll be committing this :to -current tonight or tomorrow unless I get feedback. : :See attached email for details. : :thank you, :-Alfred Perlstein - [bri...@rush.net|alf...@freebsd.org] :Wintelcom systems administrator and programmer : - http://www.wintelcom.net/ [bri...@wintelcom.net] : :3) fh(open|stat|statfs) have been haphazardly implemented, meaning I : won't be able to test them until tonight. : :Testers? Critics? Comments? please? : :If you're wondering why/what I'm doing, it's the kernel support :for a lockd that I'm working on, as well as a cleanup I thought :would make it easier to understand our filesystem code. : :I'm sure some people will be wondering: :Why does VFS_CHECKEXP take a vnode and not a mount point? :.. :-Alfred Perlstein - [bri...@rush.net|alf...@freebsd.org] I've done a quick once-over of your patch. From the point of view of the work I'm doing and the work Kirk will be doing later on, I do not think the patch will cause any problems since you are adding new VOPs for the most part rather then modifying (too many) existing VOPs. VFS, not VOP. Most of the work that Kirk and I will be doing will concentrate on namei, locking, and I/O, which you mostly avoid in your patch. In general I like the idea of implementing reasonable defaults. I would ask two things though: * First, please add comprehensive /* */ comments in front of each vfsnop_*() procedure explaining what it does, why it returns what it returns, locking requirements (if any) on entry, and side effects on return. This is just for readability. Do the same for all the procedures you are adding, in fact. The code isn't VOPs, it's VFS_ops, since they do nothing and don't block there really aren't any pre-requisites for calling them. VFS_CHECKEXP inherits the requirements of the old VFS_FHTOVP. However, dt suggested I make VFS_CHECKEXP a VOP instead of VFS, my only gripe is that exportability is determined by the filesystem, _then_ the vnode, making it more of a VFS op imo. * I think you can safely commit any elements that are not used by existing builds since they are not likely to impact existing builds operationally. Then see what you have left over. If it is not significant, commit that to. If it is significant, do more comprehensive testing on what you have left over (i.e. that impacts existing builds) and ask for another review after testing, before committing it. I'm totally lost here, can you re-phrase this? As far as the work done here, it's mostly a clean-up, no functional changes with the exception of the addition of the fh* syscalls. I guess you could call the VFS_CHECKEXP a functional change, but it's more of a re-org /pointy hair speak :) A working lock daemon would be totally awesome! The fh*() routines you are adding are roughly what you (and we) need to make progress in this area! Yes, i'd really like to get this off the ground. :) Btw, are you planning on attending any BAFUG coming up? I'd love to hear some of the preliminary stuff you are proposing for the filesystem. Thank you for your time, -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
However, dt suggested I make VFS_CHECKEXP a VOP instead of VFS, my only gripe is that exportability is determined by the filesystem, _then_ the vnode, making it more of a VFS op imo. I think dt is right here; the issue is that the operation is performed on a vnode, not on a filesystem, and thus it's a VOP not a VFSOP. Btw, are you planning on attending any BAFUG coming up? I'd love to hear some of the preliminary stuff you are proposing for the filesystem. There's one tonight in Berkeley. Be there. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: HEADS UP Reviewers. VFS changes to be committed.
: : I've done a quick once-over of your patch. From the point of view of : the work I'm doing and the work Kirk will be doing later on, I do : not think the patch will cause any problems since you are adding new : VOPs for the most part rather then modifying (too many) existing VOPs. : :VFS, not VOP. Oops, sorry. I meant VFS. Same comments apply :-) Despite all the arguing on the lists about VFS defaults and related issues, nobody is doing or contemplating any actual work in this area (i.e. VFS vs VOP) except for you, so you are not conflicting with anyone. :vfsnop_*() procedure explaining what it does, why it returns what :it returns, locking requirements (if any) on entry, and side effects :on return. This is just for readability. : :Do the same for all the procedures you are adding, in fact. : :The code isn't VOPs, it's VFS_ops, since they do nothing and don't :block there really aren't any pre-requisites for calling them. Sounds like a good comment! You and I may understand the code just fine, but the comments will help other developers. :VFS_CHECKEXP inherits the requirements of the old VFS_FHTOVP. : :However, dt suggested I make VFS_CHECKEXP a VOP instead of VFS, my only :gripe is that exportability is determined by the filesystem, _then_ the :vnode, making it more of a VFS op imo. Since you are the only one using it for the moment, do what you feel is best. Once you've begun implementing code that uses the new VFSops the appropriate place will become obvious and you can make the change (if any) then. :that to. If it is significant, do more comprehensive testing on :what you have left over (i.e. that impacts existing builds) and :ask for another review after testing, before committing it. : :I'm totally lost here, can you re-phrase this? : :As far as the work done here, it's mostly a clean-up, no functional changes :with the exception of the addition of the fh* syscalls. I guess you :could call the VFS_CHECKEXP a functional change, but it's more of a :re-org /pointy hair speak :) For example, when I add certain functionality that was turned on by a sysctl (which defaults to off), I feel that it is 'safe' to commit it into the tree even though it may not have been tested comprehensively, because nobody else is going to touch that code operationally. I make the distinction between new code that isn't exercised by systems built by other people and new code which is. The new code that isn't exercised does not need the level of testing prior to commit that code which is exercised by the masses needs. That's all. It's a rule of thumb of mine. : A working lock daemon would be totally awesome! The fh*() routines : you are adding are roughly what you (and we) need to make progress in : this area! : :Yes, i'd really like to get this off the ground. :) : :Btw, are you planning on attending any BAFUG coming up? I'd love to hear :some of the preliminary stuff you are proposing for the filesystem. : :Thank you for your time, :-Alfred I don't know re: the BAFUG meeting. I might not be in town. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
