The implementation of the
pflocal server is in the
pflocal directory, and
uses (shared code with the named pipe
IRC, freenode, #hurd, 2013-09-19
<gnu_srs> Hi, is SO_REUSEADDR supported at all on Hurd? I can only find two entries: <gnu_srs> in libdde-linux26 and pfinet/linux-src, and the functionality seems to be unimplemented. <pinotree> gnu_srs: pfinet supports it <youpi> gnu_srs: grep talks about pfinet/linux-src/net/core/sock.c: case SO_REUSEADDR: <youpi> two times <gnu_srs> Yes, and that is the implementation? <gnu_srs> I wrote a test for AF_INET and it works, but not for AF_UNIX (maybe not so interesting case). <pinotree> pflocal does not support it <gnu_srs> Is that of interest at all?
IRC, freenode, #hurd, 2014-01-14
<braunr> sudo -s eats 100 cpu :/ <braunr> possibly because of pflocal <braunr> only change on pflocal (notwithstanding the libraries) is "pflocal: improve the demuxer functions" <braunr> teythoon: why did you change the order of the function calls in sock_demuxer ? <youpi> for efficiency iirc <braunr> yes, looks reasonable
IRC, freenode, #hurd, 2014-01-16
<braunr> i suspect the "improve the demuxer functions" changes may have hard-to-understand side effects <teythoon> yes, mostly being faster <braunr> ah, the latest sudo has been fixed <braunr> haha :) <teythoon> ^^ <braunr> that one is easy to understand :) <braunr> sudo was looping around calls to pflocal <braunr> and exim crashed because of pfinet <braunr> and those servers were only affected by these changes, other than the library ones which don't seem to apply at all <braunr> but with sudo being fixed, i'm not sure it's relevant any more <teythoon> i'd say being faster could easily cause hard-to-understand side effects <braunr> ah, yes <braunr> being faster isn't the side effect itself ;p <braunr> nice, sudo was bugged on linux too, its behaviour matched its hurd version perfectly
Doesn't support fsysopts.