Summary: don't include this header if we're on Windows
Reviewed By: xavierd
Differential Revision: D33111628
fbshipit-source-id: 8bf6c7db4f023f7c348f1e1c439c15856acbf476
Summary: In the next diff, we need to use statToPostOpAttr() in another file. We will move these utility functions so we can access them from any file.
Reviewed By: xavierd
Differential Revision: D32771540
fbshipit-source-id: f4d6e2819da3ef66248134337f98eb0a938b6edb
Summary:
We account for args.dircount in this implementation (dircount is the max number of bytes we can use for holding directory information)
We *don't* account for args.maxcount. We should probably do that.
Reviewed By: kmancini, xavierd
Differential Revision: D32767072
fbshipit-source-id: c07d0f3aec5a13ed2bb3fa6960ea65e95438dff3
Summary:
The current readdir implementation uses NfsDirList to hold readdir results. Our new readdirplus implementation should use the same struct. To do this, we will add the ability to use an entryplus3 XdrList instead of an entry3 XdrList.
We also add a new constructor so we can specify which XdrList to initialize when we create an NfsDirList.
Reviewed By: xavierd
Differential Revision: D32708688
fbshipit-source-id: e2b324dd1dffc8620be89dca471043aba9b167a5
Summary:
static_assert sizeof doesn't show the actual size in clang or gcc, so
implement a CheckSize template.
Reviewed By: xavierd
Differential Revision: D32998926
fbshipit-source-id: 432fbf19eae5b4572e5a4908f9007b7242a3ae69
Summary:
We've seen several reports of users getting confused by the output of `df` and
thinking that EdenFS was using 100+ GBs of disk space. In reality, EdenFS is
simply reporting the stats from the underlying filesystem, and thus isn't a
true representation of the disk space usage.
To avoid this confusion, let's simply pretend that EdenFS doesn't use any disk
space. This isn't exactly true as the overlay and some internal datastructures
are using space already, but `eden du` is the right way to see these.
Reviewed By: fanzeyi
Differential Revision: D32536715
fbshipit-source-id: ec9b27084340d2e69cc5a14d6aa71def5fb4465d
Summary:
For restart for NFS we now have the pieces for the nfs channel to
perform takeover and for the takeover code to transfer the data.
This commit plumbs everything through so that we are able to stop and nfs
channel on takeover. this means extracting the connected socket and plubming it
to the takeover server.
Reviewed By: xavierd
Differential Revision: D31357367
fbshipit-source-id: 91973f7c149ae9209e85aa40111f41e7753db63f
Summary:
For restart for NFS we now have the pieces for the nfs channel to
perform takeover and for the takeover code to transfer the data.
This commit plumbs everything through so that we are able to start and nfs
mount during takeover. This means starting the NFS channel from an existing
connected socket.
Reviewed By: xavierd
Differential Revision: D31802788
fbshipit-source-id: 9034c1cc93e6bb64c09a203d265cf3bdedd1e160
Summary:
We are working towards supporting graceful restart on NFS so that NFS users will
have this available when we start the migration.
This commit is teaching the Server at the core of the nfsd and mountd to
support takeoverShutdown and takeoverStartup. This means stopping processing
requests when we call takover shutdown and passing the sockets (both server
socket and connected sockets) up the stack.
For now we are only supporting takeover once everything has been initialized
and not during mount or unmount.
This means for the nfsd we will only care about the one connected socket which
is being used to communicate with the kernel. we will pass through the
shutdown promise for the channel. For the mountd we only care about the server
socket which we will return from the takeoverShutdown method itself.
Then we also add being able to initialize itself from a server socket or
a connected socket.
Reviewed By: xavierd
Differential Revision: D31802790
fbshipit-source-id: 06ef4da48cd864bfa20ea0fb98485792255d98cd
Summary: This adds inode number to NFS trace event so that we can use it in ActivityRecorder to show the filename of the FS request.
Reviewed By: xavierd
Differential Revision: D30849770
fbshipit-source-id: 580faf5fccb1a225399d9aec843e23eae1874e87
Summary: This adds the support for FS events logging for NFS. For context, each type of event is assigned a sampling group that determines its sampling rate. In TraceBus subscription callback, events are sent to `FsEventLogger` to be sampled and logged through `HiveLogger`.
Reviewed By: xavierd
Differential Revision: D30843863
fbshipit-source-id: 65394d31b1197efd69c7fd4c1b24562f5abd5785
Summary: As title. `RequsetContext` allows us to track metrics such as latency and count.
Reviewed By: genevievehelsel
Differential Revision: D29835813
fbshipit-source-id: 6b85fc8f11923f530fce6d871fa2253db21bfa98
Summary: We already have AccessType for FUSE, this adds the same categorization for NFS. This allows us to easily filter events in trace stream and ActivityRecorder.
Reviewed By: chadaustin
Differential Revision: D29771074
fbshipit-source-id: a437f0693f9062fb2df3b6f618a9d8860a05df12
Summary: This diff connects the trace bus with trace fs command.
Reviewed By: chadaustin
Differential Revision: D29367135
fbshipit-source-id: f9217b286c1a21805d70b21282c10d4ad722a391
Summary: If the handler throws without returning a future, the finish event will not be published. This diff adds the `LiveRequest` to publish finish event in its destructor.
Reviewed By: chadaustin
Differential Revision: D29332452
fbshipit-source-id: 880a4b67ba47b737063a3955c9f4bdbf605f1a43
Summary:
This diff adds tracking for nfs, based on the implementation of that of `FuseChannel`.
Also commented below few questions on the implementation before working on integrating to `strace`.
Reviewed By: chadaustin
Differential Revision: D29279126
fbshipit-source-id: de6bb36dfbe2f550a91f2bf254616bbc639c0c3d
Summary:
Previously if you `sudo umount -f fbsource-nfs` then try to
`eden mount fbsource-nfs`, the mount will fail because the EdenMount already
exists and is still running.
Let's properly unmount our selfs on a force unmount like we do for fuse.
There are two potential ways to detect a fource unmount: the UMNT call to the
mount deamon or the socket to the nfsd closing. The UMNT call is unreliable
(on Linux we do not get the UNMT call on `umount -l`), so this diff pursues the
socket closing option.
When the nfsd socket is closed we trigger the EdenMount unmounting process if
this has not already started.
Reviewed By: xavierd
Differential Revision: D28329482
fbshipit-source-id: 5df8f3eb818a92536095195f1b3a9e412394fbf6
Summary:
For non-UTF8 names, the PathComponent constructor would raise an exception, and
since that exception wasn't caught by the handler itself, it would bubble up to
the RPC server and a generic "server IO error" would be sent back to the
client. Since non-UTF8 names aren't a server error, but an invalid argument, we
should instead return a different error.
Unfortunately, EILSEQ isn't an error that an NFS server can return, instead
let's use EINVAL as the argument is clearly invalid.
Reviewed By: chadaustin
Differential Revision: D28482032
fbshipit-source-id: b59044f1a76f7eac79e2df07356a0aeafa22e3c5
Summary:
The modeToNfsMode simply didn't consider all the mode bits to be translated to
the proper NFS mode bits. It now does.
Reviewed By: chadaustin
Differential Revision: D28459428
fbshipit-source-id: d879fb1be2085e44110ba552bc47d2770637fc86
Summary:
An NFS client caches the attributes of files to avoid having to request these
very frequently. What this means is that a file changed by another client (or
by the server itself) may take some time to be reflected on the client, that
time depends on the attribute caching configuration of the mount point.
For EdenFS, files can changed in 2 ways:
- Either it is changed by the user via the mount point,
- Or the user runs an `hg update`
For the first one, the client will simply update its attributes appropriately,
but for the second one, the cached attributes will only be updated when the
user does opens the file, any calls to stat prior will return the old
attributes. Since EdenFS runs on the same host, we can force the attributes
caches to be discarded by simply issuing an open call on the file that changed.
Reviewed By: chadaustin
Differential Revision: D28456482
fbshipit-source-id: 91022d35a33e436c47d94403d0c139992f880cf9
Summary:
Now that makeImmediateFutureWith exists, we can simply use it instead of
constructing a ImmediateFuture<folly::Unit> and calling thenValue on it.
Reviewed By: chadaustin
Differential Revision: D28518059
fbshipit-source-id: 0041cf863fb32efab274f11c77c76109ca9b454f
Summary:
Now that both implementation are using ImmediateFuture, we can move the
ImmediateFuture one layer up.
Reviewed By: kmancini
Differential Revision: D28302479
fbshipit-source-id: 3c2c164a90ffb42a0e7da8528f976af34fc87315
Summary:
With the Mountd code being converted to ImmediateFuture, we can now convert
Nfsd3 to use ImmediateFuture too. For now, this isn't expected to perform
better due to the InodeMap still using on folly::Future, which forces the
ImmediateFuture code to store a SemiFuture. A future change will look at
switching the InodeMap to ImmediateFuture to solve this.
Reviewed By: kmancini
Differential Revision: D28297422
fbshipit-source-id: 8b85103657e877b0f102130f2117bbe60598ed52
Summary:
macOS supports NFS servers that can be reached via a unix socket as a way to
improve performance by reducing the TCP cost. To support this, let's first
allow the socket to bind to to be passed to the RpcServer, and then pass it
through to the privhelper code.
Reviewed By: kmancini
Differential Revision: D28261423
fbshipit-source-id: 78c60aac26353d1da76a67897429b964332df8b3
Summary: `CaseSensitivity::Sensitive` is better than a mere `true` out of nowhere.
Reviewed By: kmancini
Differential Revision: D27867180
fbshipit-source-id: 39d21d3cc3b70c78c6984c3ddbd65b53520770be
Summary:
This allows unix sockets to be created in the mount. This will allow Buck to
run properly as it tries to create sockets in the repository.
Reviewed By: kmancini
Differential Revision: D27690406
fbshipit-source-id: 5725d68bdda12f3a5882ce48b6bdd02b14cdece4
Summary: This merely adds the types for the procedure
Reviewed By: kmancini
Differential Revision: D27690405
fbshipit-source-id: b94fb03658cabaece4166c29135c5fdf9a613d3c
Summary:
This is roughly the same logic as the UNLINK one with the only difference being
in the handling of "." and "..".
Reviewed By: kmancini
Differential Revision: D27684716
fbshipit-source-id: 86a95c38e6c783bc3a45c0a8b000d0210b6dd0b8
Summary:
This merely adds the types needed for the RMDIR procedure. Implementation will
follow.
Reviewed By: genevievehelsel
Differential Revision: D27684736
fbshipit-source-id: 84f5a4f3dc805e7893853b0de1dc19cb01c1319f
Summary:
To get the size in bytes, we need to multiply the quantity with the block size,
not with itself.
Reviewed By: genevievehelsel
Differential Revision: D27690857
fbshipit-source-id: 7d7ca767881b1118fc24befed230a63f342bc911
Summary:
On macOS, the mount syscall for NFS expects the arguments to be XDR encoded.
This set of argument roughly match with its Linux counterpart and appears to
start the mount process. It fails early on when trying to access the .hg
directory but this is probably an issue with the NFS server code, not of the
mounting code.
Reviewed By: kmancini
Differential Revision: D27306769
fbshipit-source-id: 697fadfddc4048ef56c3a23f75dd5bdbcc92af1b
Summary:
By moving the work to a background threadpool, we can more quickly go back to
servicing incoming NFS requests and thus allow more work to be done
concurrently. This would allow tools like ripgrep to being able to use multiple
cores to search in the code base.
Reviewed By: genevievehelsel
Differential Revision: D27194040
fbshipit-source-id: 7f1775ddaaa7eaf8776a06d05951cb936cd3fbb5
Summary:
When I wrote the NFS code, I used `std::move` a bit too much, on datastructure
where moving them is equivalent to copying them. Instead, we can simply use
references, which makes the code shorter, and thus more efficient.
Reviewed By: kmancini
Differential Revision: D27172574
fbshipit-source-id: d9f06bf3f519e3539cf5cd0a0c4e4a49ef8009a8
Summary:
In a bunch of places, the code assumes that an EdenMount is associated with a
Fuse channel. With NFS, that's no longer the case, thus let's make sure to
check the return value of mount->getFuseChannel(). In the case where it will
make sense to have something for NFS, I've either added an EDEN_BUG, or a TODO,
so we can come back to it later.
Reviewed By: chadaustin
Differential Revision: D26836431
fbshipit-source-id: c061b8f20199e5af3139a5003827f184f6eac8d4
Summary:
The NFS readdir turns out to be pretty similar to the FUSE one, with a couple
of differences. For one, it only populates the directory entry name, it also
puts a limit on the total size of the serialized result, including all the
NFS/XDR overhead.
It is not specified if the . and .. entries need to be returned, but since the
NFS spec is usually pretty explicit about these and makes it clear that this is
for the most part a client burden, I didn't add these. I may have to revisit
this later when I get to manually browse a repository.
Since the READDIR RPC doesn't populate any filehandle, the client will have to
issue a LOOKUP RPC for each entries, potentially leading to some
inefficiencies. A future diff will implement the READDIRPLUS to fix these.
Reviewed By: chadaustin
Differential Revision: D26802310
fbshipit-source-id: b821b57021d0c2dca33427975b1acd665173bc5c
Summary: This merely adds the types for the READDIR RPC.
Reviewed By: chadaustin
Differential Revision: D26802313
fbshipit-source-id: 634ff9b3f97dc4dba56d225c1fb9eae0a94c02d5
Summary:
When creating the .hg directory, Mercurial issues a SYMLINK RPC, thus let's
support it.
Reviewed By: kmancini
Differential Revision: D26785005
fbshipit-source-id: a760d55e6117cc3725444c604e3e4036f4a317b2
Summary:
As it's name implies, this RPC is used to rename files. It's not clear whether
all the error cases that the spec specifies are properly covered, but future
tests can uncover this.
Reviewed By: kmancini
Differential Revision: D26771235
fbshipit-source-id: cad1065a5277e2ab169dd34c7d485d6a4cdd4b76
Summary:
This is pattern that is repeated in several functions, let's only have one
function to make the code easier to read.
Reviewed By: kmancini
Differential Revision: D26771236
fbshipit-source-id: 64a68e90eafcea85f850374751ae7bf34f98f118
Summary: This merely adds the types needed for the RENAME RPC.
Reviewed By: kmancini
Differential Revision: D26771238
fbshipit-source-id: 7b9db7b46ffba2d7a906d0e2b60e24df0b5b055d
Summary:
The SETATTR RPC allows for changing various attributes of the file, like it's
mode, uid, gid, etc. The one piece of the NFS RFC that isn't implemented is
that NFS allows for a client to pass a ctime to the server that it needs to
check prior to setting the attributes. This is done to avoid concurrent
operations on the file conflicting with each other. This is not implemented for
now as Mercurial appears to not be using it.
Reviewed By: kmancini
Differential Revision: D26760073
fbshipit-source-id: 3474665fcf1b089ef6f7de4a6c45a26ef324240e
Summary:
This merely adds the types needed for the SYMLINK RPC, the implementation will
follow.
Reviewed By: kmancini
Differential Revision: D26737273
fbshipit-source-id: 4ed3029304fe64892e88bc05a64b4b3b19fd5460
Summary: This is merely adding the type, the implementation will follow.
Reviewed By: kmancini
Differential Revision: D26737271
fbshipit-source-id: 42de7873b271a2bf9499f1274bca50f23dc1016b
Summary: This merely adds the types for the SETATTR RPC.
Reviewed By: kmancini
Differential Revision: D26707362
fbshipit-source-id: 89cbf7a501cf4e13878cd84b6c36691d2a08594f
Summary:
Now that a large part of the RPC is implemented, being able to see what
arguments are being passed in makes it convenient for debugging.
Reviewed By: kmancini
Differential Revision: D26707363
fbshipit-source-id: 676adef996bf584140b324df1419b139f4600c91
Summary:
This reads the data from the file. One of the optimization that isn't done in
this diff would be to detect the EOF without having read return a 0-bytes long
buffer. For now this isn't done, but more plumbing in the FileInode would be
required to achieve this.
Reviewed By: kmancini
Differential Revision: D26704138
fbshipit-source-id: 82e6d4994dd5dc46372778c10d9f68f7ca1e3a87
Summary:
While creating the .hg directory, Mercurial seems to want to remove some files
too, thus let's thread this to the inode layer to allow Mercurial to continue.
Reviewed By: kmancini
Differential Revision: D26699272
fbshipit-source-id: e6d283b92e18962698c0df3c6361adfbd0c50223
Summary:
Since EdenFS doesn't support hardlinks, this is merely collecting the attribute
of the file before always failing.
Reviewed By: kmancini
Differential Revision: D26682014
fbshipit-source-id: 8c39170147023a03e87ed7a0fae66f9184b4f690
Summary:
The RPC simply queries various filesystem attributes, we merely forward what
statfs on the overlayfs gives us.
Reviewed By: kmancini
Differential Revision: D26681613
fbshipit-source-id: 5b94d05cafff8d77390fe60a3b5cf1dc3e022f42
Summary:
This simply writes the data passed in to the inode. Note that the current
implementation has a protocol violation since it doesn't sync the data written
to disk but advertise to the client that it did. This is completely wrong from
a data consistency guarantee, but is probably fine for now. Once the code
becomes closer to being production ready, this will be changed to honor the
client asks.
Reviewed By: kmancini
Differential Revision: D26681614
fbshipit-source-id: 82ad7a141be3bbe365363b1f6692ae62f253423f
Summary:
The Appender API doesn't allow us to simply append an IOBuf chain to it forcing
the entire chain to be copied to it. For the most part, this isn't an issue,
but to reduce the overhead of the READ NFS procedure, this will be a nice
benefit.
For the most part, this diff is a codemod, with a couple of places that needed
to be manually fixed. These were in the rpc/Server.{cpp,h} and
rpc/StreamClient.{cpp,h}.
Reviewed By: genevievehelsel
Differential Revision: D26675988
fbshipit-source-id: 04feef8623fcddd02ff7aea0b68a17598ab1d0f8
Summary:
The CREATE RPC is intended to create regular files on the server. It supports 3
ways of creating them: unchecked, guarded and exclusive. The exclusive mode
allows for a client to being able to re-transmit the creation and for it to not
fail when that happens. The way this is implemented requires the server to
store a cookie passed in by the client and on retransmission to compare it in
order to not fail the file creation. This complexity may not be warranted and
needed in the case of EdenFS, and the spec allows for a server to not support
this operation, thus EdenFS claims to not support it.
The 2 other modes are more traditional, guarded will simply fail if the file
already exist, while unchecked succeed in that same situation. It's not
entirely clear in the RFC what the behavior is supposed to be in the unchecked
case, and whether the attributes needs to be applied. For now, the error is
just ignored, a warning message is logged and a success is returned in this
case. In the future, setting the file attribute (in particular the mode and
size) may be necessary.
Reviewed By: kmancini
Differential Revision: D26654766
fbshipit-source-id: c2e8142b8a4ff756a868e5859fdda4b07e53bddf
Summary:
The MKDIR RPC is the first RPC that modifies the working copy. It is only
partially implemented due to the parent directory attributes not being
collected just yet. Implementing these will be essential for good caching on
the client side. For simplicity reason, this isn't done just yet.
Reviewed By: kmancini
Differential Revision: D26644056
fbshipit-source-id: f99add63a2ce5789a9aa81cefe4d04c2f4a741ed
Summary:
This is a fairly common pattern in the NFS code, and we can reduce code
duplication by automatically implementing the XdrTrait.
Reviewed By: kmancini
Differential Revision: D26639683
fbshipit-source-id: 6e9cb14ce1538834224017b8ef88955e563d6723
Summary:
The NFS RPC description is filled with variant over nfsstat3 with only 2 cases:
NFS3_OK, and the default one. I was feeling bad having to write the same code
again and again for the deserialize part of the XdrTrait, and thus came up with
a template solution that enables us to remove all of the boilerplate code.
The only drawback is that this moves the variant one additional layer down, and
that means an extra layer of brace when initializing it. From what I know,
this is caused by the -Wmissing-braces warning, maybe we could remove that
warning?
Reviewed By: kmancini
Differential Revision: D26627163
fbshipit-source-id: ab56dee42273f180b2edf4f529221a15154ac2fb
Summary:
Previously, when an argument was just a plan filehandle, I just bypassed adding
the structure and just read the handle directly from the stream. kmancini
correctly pointed out that this is a bit confusing, thus let's add the arg
struct everywhere to cut that confusion.
Reviewed By: kmancini
Differential Revision: D26649568
fbshipit-source-id: bc4d6e519450f228d151a3de7acdfc1002c43b38
Summary:
This is merely a forward to the readlink FileInode method. This allows the
.eden directory and its symlinks to be read properly.
Reviewed By: kmancini
Differential Revision: D26619947
fbshipit-source-id: d5f8ef81ce3000c0f0a2f47007affe2c0292ef31
Summary:
The LOOKUP RPC is a bit tricky as we need to special case the "." and ".."
names to represent the current and parent directories. Obtaining the parent
directory is inherently racy from the client perspective, and thus EdenFS won't
try to hold the renameLock in this case.
Reviewed By: kmancini
Differential Revision: D26597789
fbshipit-source-id: 9c8dcaf7db84f8c09f7505cab7afed48df79b754
Summary:
NFS clients will act differently depending on what kind of error is returned
from an RPC. A NFS3ERR_NOENT in response to a LOOKUP RPC may for instance
populate a negative lookup cache to avoid re-querying the same file again.
Thus, we need to translate the various errors with their corresponding
nfsstat3 values.
Reviewed By: genevievehelsel
Differential Revision: D26597788
fbshipit-source-id: d22a552196a378d6d7e9cd374e63bb8bcf436ce4
Summary:
The ACCESS RPC merely tries to see if a client can perform some action on a
file/directory. Until we have a better story around checking the RPC
credentials and passing it around, let's just return the requested access
rights as-is.
Reviewed By: kmancini
Differential Revision: D26562918
fbshipit-source-id: 468e038cc063c289b5554f3faa6a7f99be2731e4
Summary:
Now that `mount(2)` complete, we can start plumbing the rest of the mount code
to accomodate for NFS. Trying to find a common ground between Prjfs, FUSE and
Prjfs is harder than I wish it would be and thus I wasn't able to find a
satisfatory solution. For now, I went with a std::variant that stores either a
FuseChannel, or the Nfsd3. In the future once Nfs is stabilized and we have a
good understanding of how it differs (and where it doesn't), EdenMount would
probably need a good refactoring.
Reviewed By: kmancini
Differential Revision: D26500111
fbshipit-source-id: f02a2eaf8890261f150d7cdd2cdfd134aa62c2aa
Summary:
By passing the argument to the channel, we can make it so that the NFS code
correctly replies to whether it is case sensitive or not.
Reviewed By: kmancini
Differential Revision: D26500112
fbshipit-source-id: 2988eae403ff3648b50a1a8f0c978be2828ba568
Summary: The RPC just translate the various `struct stat` fields into the fattr3 ones.
Reviewed By: kmancini
Differential Revision: D26389793
fbshipit-source-id: 48c6e109d5d2cb62cab096114c37314d7833035f
Summary:
Similarly to what is done for FUSE and ProjectedFS, the dispatcher is the glue
that sits in between the protocol specific bits and the inodes layer.
For now, this only implements "getattr" but it will be filled overtime as more
RPC can be answered properly.
Reviewed By: kmancini
Differential Revision: D26389795
fbshipit-source-id: 19cf3457feec2ebc100e632cb28c20b11fdde26d
Summary: The PATHCONF call gather various POSIX attribute for the passed in file-handle.
Reviewed By: kmancini
Differential Revision: D26270239
fbshipit-source-id: 96a46c58402ce169cacc789c1df3f05f969dcd33
Summary:
The FSINFO procedure is used to collect information about this mount point and
its limits. For now, I've just used random values for most of these, I'll come
back to it later to figure out the ones that makes sense.
Reviewed By: kmancini
Differential Revision: D26269947
fbshipit-source-id: e5fdd961ea7772926208916de0179721930daeab
Summary: Instead of using a plan DBG7, let's use the strace logger to log the RPC calls.
Reviewed By: kmancini
Differential Revision: D26269946
fbshipit-source-id: e8ab7acc658463b9f0f1d4c420f63b2e0c88f46a
Summary:
With the PrivHelper now being able to try to NFS mount, we can just plug it in
the EdenMount code to actually attempt to mount EdenFS via NFS.
The mount will expectedly fail due to the FSINFO RPC not being implemented just
yet, but that will be the next step.
Reviewed By: kmancini
Differential Revision: D26266143
fbshipit-source-id: a44ae98af76b55a0c24c89e766c072c1a2e1b4fd
Summary:
Using the current EventBase can lead to unexpected behavior when the RpcServer
is created on the wrong thread. For instance, if it is created on a thread
pool, and another future is running on that same thread, the RpcServer won't be
able to accept and service new connections, potentially leading to deadlocks.
To avoid this, EdenFS's EventBase is excplicitely passed in, this will ensure
that the RpcServer is created on the proper thread.
Reviewed By: kmancini
Differential Revision: D26266145
fbshipit-source-id: 23211e3aa200c32d2f6fbbfd9ae6fb307896a873
Summary:
MSVC is broken as it doesn't understand the various macros used to generate
XdrTrait for specific types, and I can't figure out a way to make that work.
Even if I provide dummy version of these, the buck build breaks due to glog
trying to redefine the ERROR symbol that some Microsoft headers contain. For
now, let's just ifdef it out since it's unlikely that we're going to be using
NFS on Windows anytime soon.
Reviewed By: singhsrb
Differential Revision: D26293519
fbshipit-source-id: bbaf325c7d1f1688327708360244797a6d48179e
Summary:
For now, they all pretend to not be available, except the null one which does
nothing as per the RFC.
Reviewed By: genevievehelsel
Differential Revision: D26159846
fbshipit-source-id: 8d0f43f6bacc5c5a93e883e527769cb7a3b6e22b
Summary:
For now, this only registers itself against rpcbind and always reply that the
procedure is unavailable. In the future, this will service all the procedures
and forward them to a Dispatcher.
Reviewed By: genevievehelsel
Differential Revision: D26159844
fbshipit-source-id: 21908f1333ed41b3eea3fb5ce19c8e68391df103
