On 9/19/2019 9:15 AM, Matthew Wilcox wrote: > Why is it organised this way? I mean, yes, technically, rxrpc is a > generic layer-6 protocol that any blah blah blah, but in practice no > other user has come up in the last 37 years, so why bother pretending > one is going to? Just git mv net/rxrpc fs/afs/ and merge everything > through your tree. > > I feel similarly about net/9p, net/sunrpc and net/ceph. Every filesystem > comes with its own presentation layer; nobody reuses an existing one. > Just stop pretending they're separate components. The IBM/OpenAFS rxrpc implementation has been used for many services other than afs3 over the past 37 years within institutions that had source code access. rxrpc provides a light-weight rpc layer capable of pluggable per-service security classes. It offers optional end-to-end authentication, integrity protection and wire privacy. The existence of Linux rxrpc as a socket family means that it can be used to implement not only clients for AFS and AuriStorFS services beyond the fileserver but also the location service, protection service, backup service, etc. The rxrpc socket family could also be used to implement the servers. The linux rxrpc implementation does not yet have all of the functionality of the AuriStor RX implementation but it is fast. Unlike every other RX implementation, the Linux rxrpc doesn't process packets through both UDP and RX. To achieve the same performance as Linux rxrpc the AuriStor userland RX must leverage DPDK. It is my hope that as Linux rxrpc continues to improve and is built into kernels by more distributions that it will see wider use. It is a perfect match for IoT. Jeffrey Altman
begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:;;255 W 94TH ST STE 6B;New York;NY;10025-6985;United States email;internet:jaltman@xxxxxxxxxxxx title:CEO tel;work:+1-212-769-9018 url:https://www.linkedin.com/in/jeffreyaltman/ version:2.1 end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
