Add support for AF_UNIX abstract socket names: an address whose
sun_path begins with a NUL byte names a socket that lives only in a
table, never in the file system.
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 76919 Build 73802: arc lint + arc unit
Event Timeline
this is what we discussed about at eurobsdcon, my find this version very simple, given other implementation I found are more coplicated, probably I am missing some point, but it seems anyway pretty complete from my testing. (if we have an issue with performance the linked list may be converted to hash table.
You are quick! I'm still not home, thus didn't yet produce anything. Sorry! May I ask you to hold on with pushing it? May I use your implementation as a base and do more work on top? The best would be if you share your branch on github and I will make pull requests to you. At the end we can squash.
Things I want to do:
- tree(3) instead of queue(3) for the lookup
- Add a flag to tell abstract from regular one. I didn't test, but seems you can do weird things if you first bind to abstract address and then to filesystem address. Flag will allow to rule out easier that.
- Don't create new structure but unionize everything in existing unpcb.
- Userland reporting, so that netstat -u shows something meaningful.
- More tests that would test incorrect scenarios, as current test only correct use.
| sys/kern/uipc_usrreq.c | ||
|---|---|---|
| 118–125 | I think this all can be unionized into struct unpcb and you won't need extra allocation. | |
don't worry, as I explained, there is a github with an alternative which I found complicated, and I wondered if I was missing something.
about netstat -u I haven't thought about it, for sockstat I have a patch which I will put in review later where I show the abstract unix socket as '@path' @ instead of \0 we can probably do the same for netstat -u (this is what linux does in the ss command
I actually meant sockstat when said netstat. But both need to be covered.
Do you have a place you share your branch?
right now no, but I can do that once I have converted it do tree(3), but it will take some time ;)