IRC channel logs

<damo22>youpi: are we missing RPCs for generic xattrs?

<youpi>afair they're already there

<youpi>and plugged with ext2fs's support

<damo22>which project do i look in

<damo22>glibc?

<damo22>i cant seem to find the rpcs that support generic xattrs

<youpi>ext2_set_xattr seems only called from diskfs_set_translator so perhaps we're missing the RPCs indeed

<damo22>im guessing each filesystem implemented would need to implement some xattr RPCs?

<damo22>and that would need to be called from glibc?

<youpi>yes

<damo22>how do we make this generic enough such that librumpfs can work

<youpi>xattrs are relatively simple: attr_name, content

<damo22>are we keeping the gnu.translator as the attr_name ?

<youpi>for the translator record, sure

<damo22>and put the value as \0 separated strings?

<youpi>I don't remember how it is currently defined, but \0-separated is probably what was done already

<damo22>ok

<youpi>that being said, we don't need these RPCs to get translator records held in xattr

<youpi>the current get/set _translator and proper hooking in glibc should be enough

<damo22>but for example, to rsync -X and copy translator records, dont we need all the xattrs to be read the same way?

<damo22>or you mean special case the gnu.translator?

<youpi>glibc/hurd/xattr.c already special-cases it

<damo22>i thought we are aiming to remove the special casing

<youpi>in the end, yes

<youpi>but what we already have is almost ready to wor

<youpi>k

<youpi>just missing somebody to eventually take the last bits of time to actually make it work

<youpi>like a bunch of other stuff that people have contributed to the hurd, but never completely finished

<damo22>i am happy to put time in if it is worthwhile, but mostly i dont know what needs to be done

<youpi>I don't know either

<damo22>ok

<youpi>people have just left me with patches

<youpi>and that toggle to enable xattrs by default

<youpi>without knowing whether migration is actually supported at all or not

<damo22>i see

<damo22>that makes it difficult

<youpi>sure, but at least afaik the code is there

<youpi>it's just a matter of checking how to enable it and fix migratio nstuff

<damo22> /* Right now we support only a fixed set of xattr names for Hurd features.

<damo22> There are no RPC interfaces for free-form xattr names and values.

<damo22>if we modify glibc to allow free form xattrs, we need to patch hurd at the same time

<youpi>sure

<youpi>but again, we don't need that to achieve storing translators in xattrs

<damo22>would you prefer to deprecate the old field first?

<youpi>deprecate?

<youpi>why?

<damo22>as in not use it

<youpi>we just need to make our ext2fs use the new one

<youpi>make sure that it does work and the migration does work

<damo22>ok

<youpi>and then we can indeed forget about the old field

<damo22>yeah that seems like a good migration pth

<youpi>it's just that for whatever reason nobody took the time to actually do it

<youpi>I'm really amazed by the amount of code that people can produce, but not spend the time on the last 10% bit that actually enables it

<youpi>which does indeed take significant take, much more than 10% of the total time

<damo22>:)

<youpi>but what's the purpose of having done it, if not for it to be integrated

<damo22>i agree

<youpi>sure, integration is clearly not the fun part

<youpi>getting the stuff to work at all is fun

<damo22>i keep pushing on smp because i want it to work

<youpi>but heck, if it's only to remain in a corner of a git tree, what's the point

<damo22>heh, its disabled behind a flag thats all

<damo22>i think we can test it using --x-xattr-translator-records on ext2fs

<damo22>Extended attributes:

<damo22> gnu.translator (12) = "/hurd/hello\000"

<damo22>it seems to work

<damo22>but if i roll back to old records, i cant remove a xattr translator entry

<damo22>i dont think that is a problem

<damo22>how do we write a program to replace all legacy translator entries with new ones?

<damo22>maybe ext2fs should migrate them?

<damo22>youpi: i put fresh eyes on my libirqhelp patches, i think i might know how to avoid the semaphore

<damo22>testing now

<damo22>solid_black: how does pthread_cond_signal/wait work?

<solid_black>hi

<damo22>hi

<damo22> pthread_mutex_lock (&irq->irqlock);

<damo22> irq->enabled = on;

<damo22> if (on)

<damo22> pthread_cond_signal (&irq->irqcond);

<damo22> pthread_mutex_unlock (&irq->irqlock);

<solid_black>are you asking how condition variables work conceptually, or how they're implemented in HTL, or what?

<damo22>just a high level of how youre supposed to use them

<damo22>i have one thread waiting for irq->enabled

<damo22> pthread_mutex_lock (&irq->irqlock);

<damo22> while (!irq->enabled)

<damo22> pthread_cond_wait (&irq->irqcond, &irq->irqlock);

<damo22> pthread_mutex_unlock (&irq->irqlock);

<damo22>i dont understand why i need to lock the mutex

<solid_black>please see this comment of mine https://github.com/SerenityOS/serenity/pull/9610#discussion_r698034769

<solid_black>overall, you need to lock the mutex just to synchronize access to whatever "irq" is

<solid_black>condition variables don't synchronize anything, they're just for waiting for / notifying of changes, you have to use them with a mutex

<damo22>hmm do i signal after unlocking the mutex?

<solid_black>it's fine to do either, but signalling after unlocking should be a bit faster

<damo22>but if the mutex is locked by the consumer, how does the producer take the lock to enqueue the item?

<damo22>doesnt it deadlock waiting for the lock?

<damo22>or does the convar.wait unlock the mutex for a short time to allow the producer some time to take the lock

<damo22>i got signal "?"

<damo22>the backtrace looks like (); entry_point(); ()/;

<youpi>damo22: to my mind, we should make ext2fs fine with reading both old field and xattr, and write xattr

<youpi>so that it naturally migrates

<youpi>it's relatively fine for now to leave old fs with old fields

<youpi>so people can migrate smoothly

<youpi>back and forth between writing the old field or writing xattr by default

<youpi>and then we can indeed write a program to actually migrate so as to be able to rsync on linux etc.

<youpi>damo22: wait releases the lock, yes

<youpi>the point is to have atomicity between the !irq->enabled test and the actual wait

<youpi>otherwise somebody might have changed the test and signaled in between, before the wait actually sleeps, and thus the signalization is lost

<youpi>with the lock, you either see the change (and thus not wait), or not (and thus get woken)

<damo22>youpi: i fixed irqhelp

<damo22>a semaphore was required in ddekit, but not in the irqhelp library

<youpi>good :)

<damo22>youpi: ext2fs does read both old field and xattr, and writes xattr when adding new translator entries

<youpi>good

<damo22>perhaps we can set --x-xattr-translator-records on by default if it all works

<damo22>or remove the option and make it =1

<youpi>better keep the option, just change the default

<youpi>so people can go back and forth while we test

<damo22>the problem is, if you create a new translator entry with xattr, and go back to old option, it wont detect it

<youpi>ok, that's where I was having a problem then

<youpi>we want to always read both, whatever the option

<damo22>ah

<youpi>otherwise if you happen to need to downgrade your hurd package, your system is hosed

<damo22>hahaha

<damo22>yes

<damo22>youpi: i was able to ifdown /dev/eth0 and then ifup /dev/eth0 and my ssh shell survived

<youpi>thanks tcp ;)

<damo22>i thought this was not working before my patch

<youpi>that's only related to pfinet, not netdde

<damo22>ok

<etno>youpi: out of curiosity, I ran a vim=9.1.0016 package build on linux and it fails a lot of tests (less than on hurd though). I guess that packages can land in experimental only when they pass a clean build, right ? So there is something specific to my environment ? (I did "apt source vim=...; cd vim-...; dpkg-buildpackage -b")

<etno>(and "apt build-deps vim=9.1.0016" before that)

IRC channel logs

2024-03-02.log