> Unless anyone has any comments or concerns about this proposal, we're > planning on adding it to the specification as it stands.
It doesn't address threaded applications where the threads are all seperate pids (as in Linuxthreads). That probably needs clarifying Secondly it ignores all the aliasing and security issues. Eg if I lock /dev/tty and someone else wants to lock /dev/tty then its valid to do so. I think we should take a leaf from the IETF here. Design it, write it, debug it _then_ standardise it. So long as FHS standardises the lockfile paths for /dev/tty* (/dev/cua is obsolete) then the issue is sorted. Its an interesting idea, but it is pure research, might not be implementable and has a whole raft of obvious issues to be resolved like if you lock by major/minor or by name etc. Until someone proves it works and its useful I feel strongly it should be encouraged as a project but most definitely not put anywhere near the LSB
