i[ davide!davide@kor.trekweb.org ] according to http://fxr.watson.
   org/fxr/source/gnu/fs/xfs/FreeBSD/support/rwlock.h#L9
[ davide!davide@kor.trekweb.org ] you ended up w/ using sx locks as rw locks
[ davide!davide@kor.trekweb.org ] is there a particular reason to do so?
[ davide!davide@kor.trekweb.org ] do we need resources consistency across
   several sleeps?
[ davide!davide@kor.trekweb.org ] in xfs_iget() this strategy is used, for
   example.
[ davide!davide@kor.trekweb.org ] moreover, as far as I can see
[ davide!davide@kor.trekweb.org ] every locking primitive is mapped onto
   sxlock
[ davide!davide@kor.trekweb.org ] can we provide a better mapping, or am I
   missing somethin' ?
## Join #sparc64: theraven (~theraven@cpc1-cwma8-2-0-cust257.7-3.cable.
   virginmedia.com) at 06:55AM
## Signoff #sparc64: battlez (Read error: Connection reset by peer)
## Join #sparc64: battlez (~bz@bird.sbone.de) at 07:25AM
## Mode #sparc64: "+o battlez" by eadler
## Mode #sparc64: "+o battlez" by crees
>> [ davide ] Said rwlock is shoould provide sleep lock can be held in
   exclusive and shared modes. sx is a direct functional equivalent
>> [ davide ] same applies to mrlock (this one is an sx equivalent from Irix)
>> [ davide ] Then there is Linux' mutex, which is again sleepable lock (not
   to be confused with FreeBSD mutex, whihc is a non-sleeping lock). sx always
   locked exclusivery is again matching the required functionality perfectly.
>> [ davide ] rwsem of course is again sleepable read/write lock, tis time
   directly from Linux. XFS code used to be divided into two parts - core,
   which was mostly OS-neutral and OS adapter layer, that was Irix and Linux
   specific. They did not managed to keep them separate and many Linux locks
   and constructs did make its way into core, so we generally need to provide
   wrappers for both Linux and Irix variety of locks
* theraven pokes dim and brooks
>> [ davide ] Since keeping the code synced with Linux turned out to be a pipe
   dream, we just as well can start replacing wrappers with direct use of
   native locks where appropriate
[ davide!davide@kor.trekweb.org ] so are you ok to switch where appropriate?
[ davide!davide@kor.trekweb.org ] I can take this task myself, in order to
   polish the code
[ davide!davide@kor.trekweb.org ] and be a bit more consistent
>> [ davide ] If there is a reason to
>> [ davide ] Say, rwlock_t can now be replaced with FreeBSD's struct rwlock,
   looks like I used sx there only because there was no rw-variety of struct
   mtx at the time
[ davide!davide@kor.trekweb.org ] ok, worksforme
[ davide!davide@kor.trekweb.org ] this was my intuition, I wanted only to get
   a confirmation
[ davide!davide@kor.trekweb.org ] I'll prepare a patch and submit it to you
   for review
[ davide!davide@kor.trekweb.org ] it seems that XFS didn't get some love in
   the last years
>> [ davide ] rwlock is only used to protect XFS inode hashes and from the
   quick look, we never sleep while holding it
>> [ davide ] I did not touch it since FreeBSD 5
[ davide!davide@kor.trekweb.org ] pre SMP era.
>> [ davide ] No, wild SMP era
[ davide!davide@kor.trekweb.org ] or, in the SMP era screw up
[ davide!davide@kor.trekweb.org ] heh
[ davide!davide@kor.trekweb.org ] it seems the same for mrlocks
[ davide!davide@kor.trekweb.org ] are they the equivalent for rmlocks?
>> [ davide ] See above. mrlocks are coming from Linux and we definitey sleep
   while holding them
[ davide!davide@kor.trekweb.org ] ah, ok
>> [ davide ] No name similarity should be used as a base for decision, it
   will be wrong
>> [ davide ] rmlocks are non-sleepable locks that are only usable in very
   specific casesa
[ davide!davide@kor.trekweb.org ] you're right
[ davide!davide@kor.trekweb.org ] it was my fault, I didn't dig accurately
   enough
>> [ davide ] correction, mrlocks are from Irix
>> [ they ] do _exactly_ what sx does, so the map is correct
## they: No such nick/channel
>> [ davide ] they do _exactly_ what sx does, so the map is correct
[ davide!davide@kor.trekweb.org ] ok, nice
>> [ davide ]  For future, please send emails if I am not responding on the
   channel - chances of me monitoring it on work days are slim to none
[ davide!davide@kor.trekweb.org ] ok thanks
[ davide!davide@kor.trekweb.org ] sorry, are there some docs to read about in
   order to have more precise description?
[ davide!davide@kor.trekweb.org ] sometimes it's somehow difficult to
   understand what's going on from the code
[ davide!davide@kor.trekweb.org ] w/out an high level description
[ davide!davide@kor.trekweb.org ] of the operations
[ davide!davide@kor.trekweb.org ] XFS-specific, of course
>> [ davide ] There are antiquated XFS design docs from SGI, but nothing very
   specific
>> [ davide ] Need to go, continuation in email, please &
[ davide!davide@kor.trekweb.org ] ok thanks