facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-07 07:17:55 +03:00
Code Issues Projects Releases Wiki Activity
A Scalable, User-Friendly Source Control System.
428 Commits 24 Branches 62 Tags 320 MiB
Rust 45.1%
Python 20.7%
C++ 10.5%
Perl 9.1%
TypeScript 7.3%
Other 7.1%
9bbee241e6
Go to file
Jasmeet Bagga 9bbee241e6 Change API between SwSwitch and HwSwitch to indicate HwSwitch might fail some 
Summary:
Depend on D4492997
Currently, we assume that changes applied to HwSwitch always succeed (or the process exits). There is a case where we want to keep moving despite failures: when we get excessive number of route (probably) because of some misconfiguration. This diff is a step towards taking care of such situation.

We change the interface between SwSwitch and HwSwitch so that HwSwitch, when asked to apply delta of old and new state, returns either the new state if it succeeds, or returns a "pruned version of new state" if some elements of new state it was not able to apply.

SwSwitch now keeps track of two states, a state that has been applied in the hardware, and another one that is desired in hardware. SwSwitch strives to catch applied state to the desired state (while desired state is also changes as move state updates are arriving).

One issue with this diff: Warmboot is not preserving "unapplied" routes, i.e., unapplied routes get lost across warmboots. This will be fixed in a seperate diff.

One naming issue: I thought about keeping SwSwitch::getState() name intact, but thought that it is not a good idea to keep distinction of states opaque to callers. So, decided to change the name.

Reviewed By: ninas

Differential Revision: D4405751

fbshipit-source-id: c933b4418445ae49d5b8e21dea95e437a8e1593d
2017-06-02 13:38:22 -07:00
common Change API between SwSwitch and HwSwitch to indicate HwSwitch might fail some 2017-06-02 13:38:22 -07:00
eden codemod: format TARGETS with buildifier [4/5] (D5092623) 2017-06-01 17:52:40 -07:00
external get the open source build working 2017-03-06 20:28:48 -08:00
.buckconfig move eden/fs/cli to eden/cli 2017-04-14 11:39:01 -07:00
.gitignore Initial commit 2016-05-12 14:09:13 -07:00
CONTRIBUTING.md Initial commit 2016-05-12 14:09:13 -07:00
DEFS get the open source build working 2017-03-06 20:28:48 -08:00
getdeps.py replace the getdeps.sh script with a python version 2017-03-08 16:38:36 -08:00
install Make oss install script less hacky using --out argument to buck build. 2017-02-28 12:12:35 -08:00
LICENSE Initial commit 2016-05-12 14:09:13 -07:00
PATENTS Initial commit 2016-05-12 14:09:13 -07:00
README.md Fix a typo in Eden's README.md. 2016-05-13 09:32:03 -07:00

README.md

Eden

Eden is a project with several components, the most prominent of which is a virtual filesystem built using FUSE.

Caveat Emptor

Eden is still in early stages of development. We are making it available now because we plan to start making references to it from our other open source projects, such as Buck, Watchman, and Nuclide.

The version that we provide on GitHub does not build yet.

This is because the code is exported verbatim from an internal repository at Facebook, and not all of the scaffolding from our internal repository can be easily extracted. The key areas where we need to shore things up are:

  • The reinterpretations of build macros in DEFS.
  • A process for including third-party dependencies (presumably via Git submodules) and wiring up the external_deps argument in the build macros to point to them.
  • Providing the toolchain needed to power the [undocumented] thrift_library() rule in Buck.

The goal is to get Eden building on both Linux and OS X, though Linux support is expected to come first.