diff options
| -rw-r--r-- | faq/support/0-drivers.mdwn | 5 | ||||
| -rw-r--r-- | source_repositories/incubator.mdwn | 10 |
2 files changed, 5 insertions, 10 deletions
diff --git a/faq/support/0-drivers.mdwn b/faq/support/0-drivers.mdwn index 974fb612..df5cd29d 100644 --- a/faq/support/0-drivers.mdwn +++ b/faq/support/0-drivers.mdwn @@ -16,3 +16,8 @@ limits hardware support a lot, of course. For network boards, we use the [[DDE]] toolkit to run linux 2.6.32 drivers in userland processes, which provides both long-term support for new hardware and safety against driver bugs. + +Note however that we have of course not tested all drivers, we obviously don't +even have all kinds of hardware. So we can not promise that they will all +work. What probably works for sure is what we usually use: the rtl8139 or e1000 +drivers for instance. diff --git a/source_repositories/incubator.mdwn b/source_repositories/incubator.mdwn index 5e974cae..6d61a9e7 100644 --- a/source_repositories/incubator.mdwn +++ b/source_repositories/incubator.mdwn @@ -24,8 +24,6 @@ its branches, usually as a subdirectory of the current repository. The advantage of using it for `incubator` is that only one clone is needed, and it can be possible to work simultaneously on many branches (instead of only on the current branch of that clone). -The drawback is that updating a subrepository requires updating its branch -on the main clone first. Let's start checking out the `incubator` repository: @@ -46,11 +44,3 @@ simplicity, but can be created anywhere else: After this, a new `tarfs` subdirectory appears, which represents the `tarfs/master` branch. You can normally work on this new repository as usual. -As said earlier, updating `tarfs` requires fetching/pulling in `incubator` -first: - - $ cd incubator/ - incubator$ git pull/fetch - incubator$ cd tarfs/ - tarfs$ git pull/fetch - |