profile
viewpoint

jmillikin/rules_m4 9

Bazel build rules for GNU M4

jmillikin/rules_ragel 5

Bazel build rules for Ragel

jmillikin/rules_bison 4

Bazel build rules for GNU Bison

jmillikin/haskell-dbus 2

This repository is no longer actively maintained. Please use Andrey Sverdlichenko's fork instead:

jmillikin/rules_flex 2

Bazel build rules for Flex

pull request commentrust-lang/rfcs

Proposal for POSIX error numbers in `std::os::unix`.

To clarify my comment on time commitment: I'm happy to dedicate time to getting error codes for existing platforms defined, and I can directly help with platforms I'm familiar with (macOS, Linux, FreeBSD). "Support existing rustc target platforms" is a bounded effort.

My main concern with maintaining an out-of-tree create is that in five years someone's gonna come along with a port of Rust to DEC Alpha or something and will file a bug against my crate asking for coverage, and then I'm stuck. So if there's going to be a canonical place for Rust to define error codes per platform, I really want that to be in-tree with the rest of the standard library.

jmillikin

comment created time in a month

issue openedrust-lang/project-error-handling

Improving support for numeric error codes

Related discussion:

Prototype code: https://github.com/jmillikin/rust-posix-error-numbers (rustdoc)

General background

The POSIX spec defines the concept of "error numbers" (aka "error codes"), which are integers with platform-specific values used to signal error conditions from low-level OS routines. Authors of libraries that interact directly with the OS (for example, via Linux kernel syscalls) need to know the values of each error number. These values can vary between OSes and architectures, and not all error numbers defined by POSIX are necessarily defined for a given (os, arch) target tuple.

Rust currently has limited support for error numbers via auto-generated bindings to the platform's libc, but these are awkward to use in no_std contexts because a common reason to build no_std binaries is specifically to avoid depending on libc:

  • The runtime environment may have resource constraints (ram, storage) that are too small to fit a libc.
  • The platform vendor might not provide a libc at all, or if it does, it might not be sufficiently standards-compliant to be supported by the libc crate's build system.
  • There may be external requirements such as "must not depend on libc", and it is much easier to produce evidence of compliance if the build does not have the libc crate in its transitive dependency graph.

Desired project outcome

Ideally there would be an ErrorCode or ErrorNumber type defined in std, which is re-exported from a sub-crate (similar to alloc defining containers) so that it can be used in no_std mode. Ports of rustc to a target platform would define error codes for that platform as associated constants of ErrorCode, with values appropriate to the target.

Error codes are part of a platform ABI and therefore don't change once defined[0], so the ongoing maintenance overhead of this new type should be low. The primary maintenance burden will land on people adding new target platforms to rustc, and I expect that specifying error codes will not be a material increase in work considering how much is involved in porting the rest of the compiler.

[0] excepting platforms that intentionally do not provide an ABI -- it might not be possible to define the associated constants on such platforms.

created time in a month

push eventjmillikin/rust-fuse

John Millikin

commit sha 3fdb74911739e5ddc750452438cb00a048e44c1f

Add support for 32-bit ARM targets.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 1593d8e22cd838886788db5b476abb6db4cbf5e0

Add a `respond_async` feature to control presence of `RespondAsync`.

view details

push time in 2 months

delete branch jmillikin/rust-rfcs

delete branch : crates-io-namespaces

delete time in 2 months

pull request commentrust-lang/rfcs

Proposal for user namespaces on crates.io

Meta comment: I find this conversation extremely frustrating. I emailed help@crates.io asking whether the crates.io team was open to the idea of namespaces, specifically so that I could avoid having an extended debate about whether the concept of namespaced crates.io packages is acceptable to the team. I did this because I'm not being paid to write design docs for Rust package registries, and at the current time I only have an hour or two per week available to spend on programming as a hobby.

The response I received from help@crates.io is that namespaces would be an option if the right design could be proposed, so I spent the time to draft and submit this RFC. If I had been told that one or more members of the crates.io team objected to the idea of namespaces in principle, then I could have short-circuited this wasteful exercise.

Sorry, I should've been more clear. I was referring to breaking the convention that the crate name you refer to in the source code is almost always the name of the crates.io package.

I'm not sure this is a "convention", but rather a limitation of crates.io as it exists today. There is no way to register two crates with the same name, so of course the vast majority of crates will be referred to by a string that matches their crates.io package name.

The entire purpose of namespaces is to remove that limitation. It would allow more than one package to be registered with a particular crate name. In the vast majority of cases source code will continue to use crates exactly as they are named, but the crate name would be a subset of the crates.io package name.

I feel like arguing against package namespaces on the grounds of readability is similar to arguing against modules. It could be argued that use foo::bar::baz; baz(); is less clear than requiringfoo_bar_baz()` to be spelled out each time, ala C, but this is not the direction that Rust went in and I would not want to use a language that enforced globally unique function names in the name of readability.

Similarly, I feel that it is a mistake for crates.io to enforce globally unique crate names as a readability issue. The benefits of allowing multiple people to register their libraries in a particular problem domain (whether it's HTTP clients, or XML parsers, or checksum algorithms, or so on) in my opinion far outweigh the minuscule cost of referring to Cargo.toml to disambiguate the source of a crate.

I'm going to close this proposal now because it doesn't feel like it's making progress, and we all have better ways to spend our time, but the experience has left me fairly sour on crates.io as a service. I remain hopeful that at some future point you will reconsider, and thereby allow me to register libraries so that Cargo users can depend on them.

jmillikin

comment created time in 2 months

pull request commentrust-lang/rfcs

Proposal for user namespaces on crates.io

Quick idea: what if the crates.io web UI defaulted to a long and detailed crate name, so that the default is the way you want (globally unique), but if lib.name is set explicitly then that's what gets shown instead?

case 1: default behavior

[package]
name = "~jdoe/something"

is shown by crates.io as:

[dependencies]
jdoe_something = { package = "~jdoe/something" }

case 2: lib.name override (no namespace)

[package]
name = "something-long-and-always-aliased"

[lib]
name = "something"

is shown by crates.io as:

[dependencies]
something = { package = "something-long-and-always-aliased" }

case 3: lib.name override (with namespace)

[package]
name = "~jdoe/something"

[lib]
name = "something"

is shown by crates.io as:

[dependencies]
something = { package = "~jdoe/something" }
jmillikin

comment created time in 2 months

pull request commentrust-lang/rfcs

Proposal for user namespaces on crates.io

I already expressed my concern with forcing users of namespaced crates to refer to the crate ambiguously in the source code.

They're not forced to refer to it ambiguously -- the crate name exposed to rustc continues to be defined by Cargo.toml, and they can use any value they want.

These are all fine:

[dependencies]
foo = { package = "~github:jdoe/foo", version = "1.0" }

[dependencies]
jdoe_foo = { package = "~github:jdoe/foo", version = "1.0" }

[dependencies]
com_github_jdoe_foo_v1_0 = { package = "~github:jdoe/foo", version = "1.0" }

The question of what crate name a package name gets mapped to is not under the control of the package registry, and the registry has no say in what downstream users choose to name their dependency references. This is true not only because of Cargo.toml supporting package renames, but also because of extern crate foo as bar; allowing arbitrary renames within the Rust source itself.

jmillikin

comment created time in 2 months

pull request commentrust-lang/rfcs

Proposal for user namespaces on crates.io

I understand it would be annoying for this current proposal, especially if we have to use IDs in the name, but it's not the only viable namespacing scheme. For example, if we were to grant a namespace for every top-level crate, serde_derive could be published as serde/derive and referred to in the code as:

use serde::crate::derive::Deserialize;

That's not a namespace, though, that's just a longer and more complicated crate name syntax that is backwards-incompatible with the current Rust language.

What would be necessary to add namespaces, only, to crates.io so that it's possible for potential new contributors to register our packages on crates.io?

jmillikin

comment created time in 2 months

pull request commentrust-lang/rfcs

Proposal for user namespaces on crates.io

Hmm, I don't think it's incompatible with namespaces. Being able to refer to the Request item inside ~jmillikin/http in the code like this would satisfy that requirement (let's not bikeshed the syntax now):

use jmillikin::crate::http::Request;

That would be horrible, though. It further confuses the issues of crate names and package names, and it would require all users of a namespaced http crate to append a username (or, given the previous discussion a GitHub User ID) to all imports of that crate.

The goal of this RFC is to allow multiple crates named http to co-exist in the same registry, without having to change how they're referred to in code. Today, without that RFC, such a situation is only possible by using Git dependencies.

jmillikin

comment created time in 2 months

pull request commentrust-lang/rfcs

Proposal for user namespaces on crates.io

Namespaced crates should be usable inside the source code without any renaming, and that should not create collisions.

This requirement feels like it's fundamentally incompatible with the idea of namespaces, which worries me. It essentially mandates that the crates.io package namespace be 1:1 with crate names, because if it were possible to have multiple packages containing a crate with the same name then there will be ambiguity when reading source that refers to only the crate name.

I also feel like it's not reasonable to ascribe this to namespace when Cargo already provides that capability built-in. As you note, people are already experimenting with ad-hoc forms of namespacing via renames, and it doesn't seem to have caused any significant confusion in the community.

Implementing namespaces shouldn't hurt the usability and ergonomics of crates.io, for example by having random or identifiers users aren't expected to remember.

I think that crates.io package names are already pretty close to arbitrary identifiers -- when working with Cargo I use dependency stanzas like http = { package = "hyper" } so I don't have to remember the codenames during normal day-to-day programming. If crates.io continues to follow the example of NPM then the situation will only move further in that direction.

jmillikin

comment created time in 2 months

pull request commentrust-lang/rfcs

Proposal for user namespaces on crates.io

It sounds like you are saying that when a package is moved, it's effectively a new package, with no compatibility at all with the previous package? It seems like that would make namespace renaming impossible in practice, because it would break all of your packages...

I don't think it's worth over-optimizing for the rare case of package renaming, which is currently not possible anyway.

jmillikin

comment created time in 2 months

pull request commentrust-lang/rfcs

Proposal for user namespaces on crates.io

If that's the goal, what could prevent you from publishing today the crate http as jmillikin-http?

Please refer to previous discussions linked in the RFC for why ad-hoc name patterns do not solve the issue addressed by namespaces.

My concern is not with author choosing weird renames, but with having multiple crates from different authors being renamed as the same thing across multiple project. How would you personally handle depending on ~foo/http in a codebase and on ~bar/http in another unrelated codebase?

Finding the definition of a symbol already requires inspecting Cargo.toml and Cargo.lock to find which package and version is being depended on, so nothing changes here. The question of whether crate names and package names could differ was resolved as soon as Cargo added that functionality.

jmillikin

comment created time in 2 months

pull request commentrust-lang/rfcs

Proposal for user namespaces on crates.io

I feel like this would prevent any project the author expects to possibly be successful from using user namespaces.

That seems fine. The goal is not to force use of namespaces, but to allow authors to upload crates with names that already exist as registered packages.

Losing this property would be really bad IMO, as every project would have (for example) http::Request pointing to something different. Having to check the Cargo.toml every time I want to open docs.rs would be far from ideal for me.

If you find authors renaming crates in ways that don't make sense, that sounds like something to take up with those authors.

The primary alternative to this RFC for me is registering packages named with UUIDs, so that I don't have to worry about what might already be registered. This would work about as well for my workflow, which does not use Cargo, but I suspect that other people would be bothered by UUID names in crates.io and docs.rs.

jmillikin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

Proposal for user namespaces on crates.io

+- Feature Name: crates_io_user_namespaces+- Start Date: 2020-08-29+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++This RFC proposes extending the crates.io package naming format to allow+per-user namespaces. A crates.io user Jane Doe signed in with the GitHub+account `"jdoe"` would be able to publish crates with names prefixed by+`"~jdoe/"` Tooling that operates on crates.io package names, such as docs.rs,+will recognize this syntax and drop the prefix to compute the crate name.++# Motivation+[motivation]: #motivation++crates.io currently places all registered packages in a single flat namespace.+This simplifies some aspects of package discovery, but adds friction for users+who prefer to name packages after their purpose rather than use an opaque+codename. Additionally, due to the large number of registered packages, it is+often difficult to find a name that is short enough to be ergonomic when+used as a symbol in Rust source code.++Introducing per-user namespaces will allow every crates.io user to upload packages without worrying about crate name conflicts.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++TODO: Is a guide-level explanation needed at all? There's already documentation+on how to define dependencies in Cargo where the package name is different from+the crate name, and this isn't adding any new capabilities.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++The crates.io package name validation would be relaxed to allow package names+starting with a namespace prefix. This RFC defines the "user" namespace prefix+format. Given a user with a crates.io profile at `"https://crates.io/users/X"`,+their user namespace prefix is `"~X/"`. Existing rules regarding allowed+character set, minimum/maximum crate length, and reserved crate names continue+to apply to the crate name component of a namespaced package name.++The syntax and allowed character set of the username portion is the same as for+crates.io usernames.++If a user requests that their username be changed (e.g. via a support request),+then any existing package uploads under their old user namespace will be+redirected to their new username. This RFC does not specify whether new versions+would be available under the old package name, and recommends the crates.io+team decide that based on expected support load.

If a package author wants to let users depend on them without copy-pasting a [dependencies] line from the readme, then they'll have to register a non-namespaced crate.

jmillikin

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentrust-lang/rfcs

Proposal for user namespaces on crates.io

+- Feature Name: crates_io_user_namespaces+- Start Date: 2020-08-29+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++This RFC proposes extending the crates.io package naming format to allow+per-user namespaces. A crates.io user Jane Doe signed in with the GitHub+account `"jdoe"` would be able to publish crates with names prefixed by+`"~jdoe/"` Tooling that operates on crates.io package names, such as docs.rs,+will recognize this syntax and drop the prefix to compute the crate name.++# Motivation+[motivation]: #motivation++crates.io currently places all registered packages in a single flat namespace.+This simplifies some aspects of package discovery, but adds friction for users+who prefer to name packages after their purpose rather than use an opaque+codename. Additionally, due to the large number of registered packages, it is+often difficult to find a name that is short enough to be ergonomic when+used as a symbol in Rust source code.++Introducing per-user namespaces will allow every crates.io user to upload packages without worrying about crate name conflicts.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++TODO: Is a guide-level explanation needed at all? There's already documentation+on how to define dependencies in Cargo where the package name is different from+the crate name, and this isn't adding any new capabilities.

Cargo supports specifying the package name, so something like this (copying from https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html):

[dependencies]
foo = { version = "0.1", package = "~someuser/foo" }
jmillikin

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentrust-lang/rfcs

Proposal for user namespaces on crates.io

+- Feature Name: crates_io_user_namespaces+- Start Date: 2020-08-29+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++This RFC proposes extending the crates.io package naming format to allow+per-user namespaces. A crates.io user Jane Doe signed in with the GitHub+account `"jdoe"` would be able to publish crates with names prefixed by+`"~jdoe/"` Tooling that operates on crates.io package names, such as docs.rs,+will recognize this syntax and drop the prefix to compute the crate name.++# Motivation+[motivation]: #motivation++crates.io currently places all registered packages in a single flat namespace.+This simplifies some aspects of package discovery, but adds friction for users+who prefer to name packages after their purpose rather than use an opaque+codename. Additionally, due to the large number of registered packages, it is+often difficult to find a name that is short enough to be ergonomic when+used as a symbol in Rust source code.++Introducing per-user namespaces will allow every crates.io user to upload packages without worrying about crate name conflicts.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++TODO: Is a guide-level explanation needed at all? There's already documentation+on how to define dependencies in Cargo where the package name is different from+the crate name, and this isn't adding any new capabilities.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++The crates.io package name validation would be relaxed to allow package names+starting with a namespace prefix. This RFC defines the "user" namespace prefix+format. Given a user with a crates.io profile at `"https://crates.io/users/X"`,+their user namespace prefix is `"~X/"`. Existing rules regarding allowed+character set, minimum/maximum crate length, and reserved crate names continue+to apply to the crate name component of a namespaced package name.++The syntax and allowed character set of the username portion is the same as for+crates.io usernames.++If a user requests that their username be changed (e.g. via a support request),+then any existing package uploads under their old user namespace will be+redirected to their new username. This RFC does not specify whether new versions+would be available under the old package name, and recommends the crates.io+team decide that based on expected support load.

Would using a format like ~github:123456 work, then?

I really have no attachment to the details of how user IDs are represented, and if a particular identity provider does not provide stable user names then whatever stable identifier they support will have to do.

jmillikin

comment created time in 2 months

PullRequestReviewEvent

pull request commentrust-lang/rfcs

Proposal for user namespaces on crates.io

Namespaces are taken permanently, as soon as any crate is published under that namespace, so you still have the issue of exhausting the set of namespaces/picking an unused namespace. Also, because namespaces grant you so much power, there's a much stronger motivation for people to take all the short namespace names early and sit on them.

Users already have to pick an unused username before they can register with an identity provider, which happens before they sign up for a crates.io account. I am not expecting a rush of people signing up for short GitHub names so that they can get "powerful" crates.io user namespaces.

If you allow changing a namespace, or moving a crate between namespaces, you have to set up appropriate redirects from the old namespace. You now have the problem that multiple crate identifiers can refer to the same crate. Cargo needs to know whether two crates are the same or not, so now cargo needs an internet connection to do that dependency resolution...

I don't see why Cargo would need to know or care whether two crates.io packages are the same crate. It can't know that today, right? I can upload a single crate under many package names and Cargo would treat them all as separate dependencies.

The goal of redirects would be to avoid breaking previously registered package versions. Any other semantics can be decided by the crates.io maintainers such that it minimizes their support burden.

It's unclear how things like ownership transfer could happen when crates are tied to a specific user?

I don't think ownership transfer -- removal of the original author's ownership -- would be possible for packages in a user namespace. If a package should be collectively owned, it should not be registered in a user namespace. If a user's package becomes so popular that they want it to become its own project, or if a user wants to hand off ownership to others, then they'll need to re-register it under a different name and communicate this to their users.

I would rather not lock ourselves in to github usernames specifically...

Would the proposed alternative of explicit namespaces for identity providers solve this concern?

In any case, this would mean that users would need to override the symbol name in more cases, which could cause problems with macro expansions trying to refer to symbols under the wrong name. (I'm not sure this is a solved problem yet...)

I don't think this would affect how often symbols need to be renamed, or macro expansions. Macros already must refer to their own crate with $crate:: so that they can be independent of how their caller refers to their crate, and there's no need to rename symbols when build tools like Cargo have native support for separating crate names from package names.

This doesn't necessarily mean that we have to use the username as the scope. If this is really such a huge issue, crates.io could have a feature to generate an unused crate name based on a particular word.

There's no need for crates.io to have that functionality. UUIDs can be valid crates.io package names, and tools such as https://www.uuidgenerator.net/ can generate UUIDs easily.

The goal of this proposal is to avoid the ergonomic issues that result from using generated package names.

Ultimately, the requirements of crate names being "meaningful", "unique" and "permanent" are always going to be in conflict, and the "unique" and "permanent" constraints are non-negotiable.

We should be careful to distinguish "crates.io package" from "crate", because crates are consumed by rustc and have different naming requirements. There is no reason that a crate name must be globally unique -- only unique within a single [dependencies] section or rustc invocation.

jmillikin

comment created time in 2 months

pull request commentrust-lang/rfcs

Proposal for user namespaces on crates.io

cc @steveklabnik, who posted the original thread on crates.io package naming policy.

jmillikin

comment created time in 2 months

PR opened rust-lang/rfcs

Proposal for user namespaces on crates.io
+169 -0

0 comment

1 changed file

pr created time in 2 months

push eventjmillikin/rust-rfcs

John Millikin

commit sha 9bf29d2c57d8d2bf1b98a014a1734c59173f9f93

Proposal for user namespaces on crates.io

view details

push time in 2 months

push eventjmillikin/rust-rfcs

John Millikin

commit sha 397f02aff317aeffa111c9f1c768a394defb56d2

Proposal for user namespaces on crates.io

view details

push time in 2 months

push eventjmillikin/rust-rfcs

John Millikin

commit sha 14c937a78d026830665bb49cbc767f9e788c62df

Proposal for user namespaces on crates.io

view details

push time in 2 months

push eventjmillikin/rust-rfcs

Dylan MacKenzie

commit sha d364261e02ec7ce5323c97d7e3dc6e2a1fb28a53

Inline `const`

view details

Dylan MacKenzie

commit sha 1c6bc1bed859e8e4f63be1b6455ea959f085adab

Typo

view details

Dylan MacKenzie

commit sha 40bbfebcf8fa9ad35c052ed51f6582f91508ed30

Add RFC PR number

view details

Dylan MacKenzie

commit sha d7f15624f9a4ebc6ce4e729fcfa262c8c600c246

Remove `PathPattern` change

view details

ecstatic-morse

commit sha 275f29def496da627ef508467b0ce83d91a5aa2c

Fix typo Co-authored-by: Martin Carton <cartonmartin+github@gmail.com>

view details

Dylan MacKenzie

commit sha 25963089258423baca3fe840279485519ca7f10c

Add constants to list of things that should be promotable

view details

Dylan MacKenzie

commit sha 0e86426c9cca5c50d852951e0b5ee5fd4c545239

Update naming discussion

view details

Dylan MacKenzie

commit sha b35e5595f225a89efdf3fbac58cb153b1f56dc29

Expound on possibility of reducing the set of promotable expressions

view details

Dylan MacKenzie

commit sha 6372ce932d36870cf0f24b3bf87ce053b0372026

No version is idiomatic

view details

Dylan MacKenzie

commit sha 20d7f70abf4064867654c44d1edcbc33c4fb6a2d

Mention Zig `comptime`

view details

Dylan MacKenzie

commit sha dff0ecc918b825aacf978e034d36637f250a87da

Add "Generic Parameters" section to unresolved questions

view details

Dylan MacKenzie

commit sha ed83797051479925b064cb4209a8ad0530e3c597

Link to const type inference RFC

view details

Dylan MacKenzie

commit sha c89075d26348c179989b69188619b8e05d34c546

Bold usernames

view details

ecstatic-morse

commit sha c233d4de2d90a91354176e6b2caf19cdd1c4eb6a

Fix typo Co-authored-by: Jake Goulding <shepmaster@mac.com>

view details

Dylan MacKenzie

commit sha e67c40bb165dc3bd24859ef5785102dee30b6005

Better const pattern example

view details

Dylan MacKenzie

commit sha 798b26a6b75e2113463ca36901b31db8a92b0e13

Update resolved/unresolved questions in RFC - "Generic parameters" are resolved to work just like array length expressions. - Added section about containing `unsafe` blocks. - Moved "lints" to unresolved questions.

view details

Dylan MacKenzie

commit sha 1f9d6976fe7334e572d02006fb457f63d1db352e

Remove value judgement on separability

view details

Dylan MacKenzie

commit sha e679523b6863aa48700165645ef177508e5437ee

Make promotion section more hypothetical

view details

Dylan MacKenzie

commit sha ee9164a2f6cccc14caef7c36b12a52d86bb00f35

Fix typos

view details

Niko Matsakis

commit sha 49dba2b393d97dd3bbe16790d9610e200b57184b

Merge remote-tracking branch 'ecstatic-morse/inline-const'

view details

push time in 2 months

create barnchjmillikin/rust-rfcs

branch : crates-io-namespaces

created branch time in 2 months

issue closedjmillikin/rust-fuse

Remove dependency on libc

  • [x] Replace calls to libc::mount(), libc::getuid(), etc with raw syscalls.
  • [x] Use https://github.com/rust-lang/rfcs/pull/2973 or hardcoded target-specific values for POSIX error numbers.

libstd currently depends on libc, so until that's fixed also allow rust-fuse to be optionally #![no_std]:

  • [x] Change FuseMount to return Channel rather than std::fs::File.
  • [x] Verify that a #![no_std] binary linking with rlibc can produce working FUSE servers.

closed time in 2 months

jmillikin

push eventjmillikin/rust-fuse

John Millikin

commit sha 854f03564c30ad3fe8a047980a25a73dd53bba56

Render `FuseMount` implementations in `cfg(docs)` mode.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 59dfc4db0c9c489e4a6e23f6349d75917acf5009

fuse-v0.0.1-854f03564c30ad3fe8a047980a25a73dd53bba56

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha c8c85077dc964ba5678eedb4128ee2544a97d588

Expand the README

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha df4ffaf362f25fb6152545e3c8d7b9f6bde27a3f

fuse-v0.0.1-0138f26448d3f20dacec218561c99634c3e69dab

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 0138f26448d3f20dacec218561c99634c3e69dab

Fix all warnings.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 4d4b625edb34fc9cb0337e8fa17f2a031012c426

Fix all warnings.

view details

push time in 2 months

issue closedjmillikin/rust-fuse

Add logging hooks to `FuseServer`

Necessary hooks:

  • [x] New request: let the user access header properties including request ID, opcode, pid/uid/gid. Possibly also message length.
    • Note this implies we'll need a stable interface for opcodes.
  • [x] Unknown request: a request came in with an opcode that couldn't be dispatched by FuseServer.
  • [x] Unhandled request: a request was not handled by the users' FuseHandlers.
    • This will be invoked in the default implementations of the handlers, prior to responding ENOSYS.
  • [x] Write error: if the kernel rejects a write() the server currently drops that error on the floor. It should be loggable.

closed time in 2 months

jmillikin

push eventjmillikin/rust-fuse

John Millikin

commit sha f1c7ab31381a5f1e32781f9588d0dd8fdb6fc182

Remove self-return from `ReaddirEntry::set_file_type()`

view details

John Millikin

commit sha d5cda1d0ad1c249652529fe56668323cfb08c30e

Read in a loop to handle `EINTR` and `ENOENT`.

view details

John Millikin

commit sha cb1dea80889e47ec0b30960e5a2a4cbc4c02ea1a

Expand `ServerHooks` to support error reporting and `no_std` servers. issue: https://github.com/jmillikin/rust-fuse/issues/8

view details

John Millikin

commit sha 18c8601ae8271edcb36281432767b0f12b4d2ed1

Add a server hook for reporting unhandled requests. issue: https://github.com/jmillikin/rust-fuse/issues/8

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha df5eb4571d92271c9dcf308fe31bea35dfb91151

Use `Result` for return value of failable response methods.

view details

John Millikin

commit sha 6013a9db9ad119818ed6dfbf687eb12ebe7dae8b

Remove version negotiation from `fuse_init` and `cuse_init` handlers.

view details

John Millikin

commit sha 9d1336031bad7d05192534a7c2ae41e257f2aa45

Add `ErrorCode::ERANGE` for use with xattr handlers.

view details

John Millikin

commit sha 7a7d003d98bd9579fe55c5563556a6825e8a2823

Bring the APIs for `ReaddirResponse` and `ListxattrResponse` similar.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 072e68508f7858ca0307bc51dcf4637684625b55

Make `fuse::io::Error` an opaque struct.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 2fed63dd3c35dcb8d2b15a79ec3e3e7e3d9dce26

Add `ServerHooks` trait with methods `on_request` and `on_unknown`. issue: https://github.com/jmillikin/rust-fuse/issues/8

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha d093303c0c15aec60e20ec2f91322a4bfc958020

Add feature annotation to docs of `Channel::send_vectored()`

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha ced54bbf00f2b37c7a038ac7833d40a140c7443f

Fix no_std build (broken by a63571d)

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha b4e224aab99a09b5b2c25b9635f09a0bd027428a

Fix handling of ENODEV during FUSE unmount (broken by 4b5ea05).

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha a63571d8a6e2b55b79378058d7ccdde3c371e292

Put nightly-dependent functionality behind non-default features.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 400557dda059020db741cc78f853c1d6994acfa9

Unify cfg features for unstable FUSE and CUSE handlers.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 83edeeabc5550e91950c67fadca0662c5fcf74b5

Rename `RespondOnce` to `Respond`.

view details

John Millikin

commit sha ee0b43ad0d83380e717539acd13635dcf86fbbb9

Use `RequestHeader` for `ServerContext` header fields.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 4b5ea054c1ba33a0472eeca2248d11bdac0f2a64

Rework server implementation to support no_std servers. issue: https://github.com/jmillikin/rust-fuse/issues/11

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 4a1e80840d91e8fb55949616c557c26a0bcecc0d

Add stringified error codes to the `ResponseHeader` debug format.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 49bd418f81e69debb3492dfa0fe9684a1f9ccbfd

Declutter the public API index page a bit by adding `io` submodule.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha e8afdbc8e0702e08f27d50fabfe6168982a0457b

Add types for inspecting the full header of unknown requests. issue: https://github.com/jmillikin/rust-fuse/issues/8

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 07a3c69f35d8b370f5eec8b5fadb3536251ef1b4

Rename concrete channel types backed by `/dev/{cuse,fuse}`.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha bf7b6878e7a9b5b69cf4d5db9a2c7242bf81af9b

Calculate `read_buffer_size` from negotiated `max_write`.

view details

John Millikin

commit sha 8c168622ac6780afa0346a01d7ffa02cab15b33d

Mount data must be strictly less than `PAGE_SIZE` (not LTE)

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 03b0dab50b58eb9ffd10c54bfb9faf45e1caad4a

Rename `{Cuse,Fuse}Channel` to `{Cuse,Fuse}ServerChannel`.

view details

John Millikin

commit sha 2f06ca85b10b1d9bf48e8a9071f93ab49780ea82

Respond with -EIO on request parse error or response send error.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha da52739c9943385a14f60d270c3e4fd8409ba0a1

Fix links to `FuseHandlers` in request/response struct doc comments.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha e3702855161bbe5cd80e18d557f20091bd05b40e

Bring back `FuseServerBuilder`, moving mount impl to a new trait.

view details

push time in 2 months

issue closedjmillikin/rust-fuse

Support CUSE

Steps:

  • [x] Define CuseInitRequest and CuseInitResponse types
  • [x] Define CuseHandlers
  • [x] Define CuseServer and CuseServerExecutor

closed time in 2 months

jmillikin

push eventjmillikin/rust-fuse

John Millikin

commit sha 8df76b16ffdae1a848cb2eb623f25edaca161156

Implement `CuseServer` and `linux::CuseServerBuilder`. issue: https://github.com/jmillikin/rust-fuse/issues/1

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha d9468794dedf058605bff112f86ff3d8506f057d

Implement `CuseServer` and `linux::CuseServerBuilder`.

view details

push time in 2 months

issue closedrust-lang/cargo

`cargo doc` doesn't pass `--cfg doc` to rustc

Problem PR https://github.com/rust-lang/rust/pull/53076 added support for #[cfg(doc)], which conditionally enables code when being built for documentation. This cfg is set by rustdoc when parsing a module, but is not set by Cargo when running rustc prior to running rustdoc.

This causes confusing failures to document code when the current platform can't build it, but should be able to document it.

Steps Given this library:

pub struct T {}

impl T {
    pub const SOME_CONST: u32 = match () {
        #[cfg(target_os = "linux")] _ => 1,
        #[cfg(target_os = "freebsd")] _ => 2,
        #[cfg(doc)] _ => 3,
    };
}

A macOS machine should be able to run cargo doc to build docs, even though the library doesn't support that platform. Currently this fails

To confirm that this is caused by a bad rustc argv, invoke Cargo with RUSTFLAGS="--cfg doc" cargo doc and observe that it builds the docs successfully.

Possible Solution(s) The best solution would be to pass --cfg doc to rustc when building docs.

Notes

Output of cargo version:

$ cargo --version
cargo 1.47.0-nightly (1653f3546 2020-08-04)

closed time in 2 months

jmillikin

issue commentrust-lang/cargo

`cargo doc` doesn't pass `--cfg doc` to rustc

Closing; per discussion in https://github.com/rust-lang/cargo/pull/8602, this won't be possible to change without breaking backwards compatibility (and it's unclear whether changing it would even be correct).

jmillikin

comment created time in 2 months

delete branch jmillikin/cargo

delete branch : rustc-cfg-doc

delete time in 2 months

PR closed rust-lang/cargo

Run rustc with `--cfg doc` when analyzing dependencies in `cargo doc`. S-waiting-on-review

Proposed fix for https://github.com/rust-lang/cargo/issues/8601

This is my first PR to Cargo and I am not familiar with the codebase. If this isn't implemented properly, please tell me and I'd be happy to make changes.

+83 -25

8 comments

10 changed files

jmillikin

pr closed time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 6cadea0882f5051ae3cc322b08a64c7e06cd0198

Add non-server types for CUSE (`CuseHandlers`, `CuseInit*`) issue: https://github.com/jmillikin/rust-fuse/issues/1

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 59f12e080e85715595f250682f090cb7811e4aff

Fix and/or silence some `dead_code` warnings.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha a257e8ba4a5a9c8affaf3a8af19c896e71b51af6

Stabilize `FuseServer` and `FuseServerExecutor`.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 63e69f2d32dd27e7101bf8a778831e93a6a25fee

Add `FileMode` and stabilize `FileType` as an enum.

view details

push time in 2 months

issue closedjmillikin/rust-fuse

Stabilize handlers for minimal useful filesystem

Steps:

  • [x] Annotate all methods of FuseHandlers with their stability, with #[cfg].
  • [x] Similarly request/response types for those handlers, possibly at the field level.
  • [x] Generate docs with unstable handlers included.
  • [x] Have a checklist to define when a handler is stable
    • Request and response structs have lifetimes
    • All request/response fields are public and well-typed.
    • The Debug trait is implemented correctly (doesn't expose internal state)
    • Handler, request, and response are reasonably well documented.
  • [x] Stabilize types and handlers required for a minimal read-only filesystem.
    • [x] FuseHandlers::fuse_init()
    • [x] FuseHandlers::forget()
    • [x] FuseHandlers::getattr()
    • [x] FuseHandlers::lookup()
    • [x] FuseHandlers::open()
    • [x] FuseHandlers::opendir()
    • [x] FuseHandlers::read()
    • [x] FuseHandlers::readdir()
    • [x] FuseHandlers::readlink()
    • [x] FuseHandlers::release()
    • [x] FuseHandlers::releasedir()
    • [x] Entry and attribute wrappers
  • [x] Stabilize the handlers required for a minimal mutable filesystem.
    • [x] FuseHandlers::link()
    • [x] FuseHandlers::mkdir()
    • [x] FuseHandlers::mknod()
    • [x] FuseHandlers::rename()
    • [x] FuseHandlers::rmdir()
    • [x] FuseHandlers::symlink()
    • [x] FuseHandlers::unlink()
    • [x] FuseHandlers::write()

closed time in 2 months

jmillikin

push eventjmillikin/rust-fuse

John Millikin

commit sha ac24220ef668c7c46910c38f847934f1999c77a6

Use more flexible definitions for bitflag structs.

view details

John Millikin

commit sha 4f650d94429ad6648bf00f069d7a59368633ba2f

Stabilize `FuseHandlers::rename()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

John Millikin

commit sha e69338684bcf7f84391a8865371172faef18435c

More clearly distinguish flags set by `open()` or `opendir()`.

view details

John Millikin

commit sha a87b2b47e3ea60f56e353c12c550e0986b5d4642

Stabilize `FuseHandlers::write()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 6feb2d2fa1cbcc1d48d01431c809b965bdc6d146

Manually run `rustfmt` because `cargo fmt` is skipping some files.

view details

John Millikin

commit sha 01915f31a46713adbeb0fd55de25956d0d76cdc5

Stabilize `FuseHandlers::rmdir()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

John Millikin

commit sha 7236edd4fe865bfe082ed7a7141566e9bf4afda1

Stabilize `FuseHandlers::symlink()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha d9128307101435b1d0c129725195374945039a27

Stabilize `FuseHandlers::link()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

John Millikin

commit sha b987e2699176f415b7e61b5a9d582659b25066a6

Stabilize `FuseHandlers::mkdir()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

John Millikin

commit sha 3c1fedcddc37dae9091fafdce3f4b867232be79b

Stabilize `FuseHandlers::mknod()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

John Millikin

commit sha ba5cf06f5af8f84d7e3cdc2f1dc6153225f881be

Stabilize `FuseHandlers::unlink()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 2 months

pull request commentrust-lang/cargo

Run rustc with `--cfg doc` when analyzing dependencies in `cargo doc`.

Hmm, that's frustrating, but I think I understand the compat issues now.

Is there any chance this might be available as a Cargo option (CLI flag, manifest field, env var...) or should I just try to find a different macro layout that Cargo can handle?

jmillikin

comment created time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 60792ecf03747850c5c8ddd30abc8bd8bc673aca

Add `no_std` feature and mark everything above `protocol` as std-ful. issue: https://github.com/jmillikin/rust-fuse/issues/11

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 112be3edf2d8a90c14660e0e39590ebb84cee63c

Add `Channel` to the public API to prepare for user-defined platforms.

view details

John Millikin

commit sha a73f5a990798583fcd6fd0b14260e151dba12dca

Separate parse errors from IO errors, and channel building from server building.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 464d8e750b421b8282aba7293a4165dfeb483ea9

Add `Channel` to the public API to prepare for user-defined platforms.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 112be3edf2d8a90c14660e0e39590ebb84cee63c

Add `Channel` to the public API to prepare for user-defined platforms.

view details

John Millikin

commit sha ce510fce00d3304d919c7838854aa973cba3bf2c

Separate parse errors from IO errors, and channel building from server building.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha e191261febbc475ec4844a0da3eb5f5971f69a8e

Add `Error` and `ErrorCode` types for abstract POSIX error numbers.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha b8831b53007a84ead2b5be14401b37422ef1facc

Return named types from constructors for better docs.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha c2275e852b376b749e744d1bae997c8d65fceff5

Stabilize `FuseHandlers::getxattr()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

John Millikin

commit sha f074f2ba1f4e008a51039766e238cc509a713d05

Rename `try_new_entry` to `try_add_entry` to match future listxattr.

view details

John Millikin

commit sha e1bd10a4a2e5e04756b286e1d5d819f4320e7069

Stabilize `FuseHandlers::listxattr()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 2 months

pull request commentrust-lang/cargo

Run rustc with `--cfg doc` when analyzing dependencies in `cargo doc`.

Would it be OK to run rustc twice? First using the current settings, then if that fails, again with --cfg doc?

jmillikin

comment created time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 37b687018a19005ae7b6b2456c0708ee41b084d3

Rename `Name` back to `NodeName` to avoid conflicting with xattr names.

view details

John Millikin

commit sha a7c3b4b2280ae75aad1e58cb250e189e754fc993

Turns out `NAME_MAX` is 255 on Linux, not 1024.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha e196652839ff42f80162c76b5428b45324e3c6ba

Remove libfuse-derived docs from `FuseHandlers`. They're difficult to integrate into the rustdoc style, and contain a lot of protocol-level info that would be better placed in a separate document.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 615bce9cfd197ab47fbc4b7ae77dc6a00965ef59

Use non-exhaustive structs with public bool fields for flags.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 6375e43e36bd999d218d36332badec5ef05eeba0

Reorganization to get cleaner docs.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 5b3a19170da6e00de3685abfc2f11d1c7cdd964f

Only respond with `FUSE_INIT` flags known to the library.

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 47884dd2f1fc6fc84e6a0cac702be2a529a135e3

Disable `FUSE_READDIRPLUS` flags until that handler can be implemented.

view details

John Millikin

commit sha cc283de46d2ffc0354250a4a0f32d99b8e74288d

Stabilize `FuseHandlers::getattr()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 30c44bcf6cb40cd1c9885024578f6dd24786a751

Stabilize `FuseHandlers::lookup()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 2 months

pull request commentrust-lang/cargo

Run rustc with `--cfg doc` when analyzing dependencies in `cargo doc`.

Thanks for the PR! Unfortunately I don't think this is a change we can make, because it is backwards incompatible, and some libraries will fail with this change.

I don't understand how this change would be backwards incompatible. The same crate gets passed to rustc and then to rustdoc, so if the presence of --cfg doc breaks compilation for a crate, I would expect that to manifest in the current behavior already.

Is it possible to give an example of a crate that would be broken (e.g. from a Crater run), or even a code snippet of something non-pathological that would be broken by this change?

jmillikin

comment created time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 25ce67fd552f4d86b53854d8375b1bf51a1a8de8

Clip the buffer returned from `AlignedVec::get()` and `get_mut()`.

view details

John Millikin

commit sha 5c543c6e0cd9d5ae51ef25e781f20c0006f0433d

Enforce platform-specific `NAME_MAX` in `node::NodeName` pub constructor.

view details

John Millikin

commit sha 571e8ee000ffb36cc44811ef752ff5334955fa7d

Stabilize non-plus portions of `FuseHandlers::readdir()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 2 months

issue openedrust-lang/rustfmt

Braced expressions guarded by #[cfg] attrs are reformatted into invalid syntax

Describe the bug

Given this input file:

pub const NAME_MAX: usize = {
    #[cfg(target_os = "linux")]   { 1024 }
    #[cfg(target_os = "freebsd")] {  255 }
};

rustfmt with default settings converts it into

pub const NAME_MAX: usize = {
    #[cfg(target_os = "linux")]
    {[cfg(target_os = "linux")]   {        1024
    }
    #[cfg(target_os = "freebsd")]
    {[cfg(target_os = "freebsd")] {        255
    }
};

, which does not parse.

Expected behavior

Formatting code should not generate un-parseable code.

Meta

I can reproduce this on nightly (rustfmt 2.0.0-rc.2-nightly (0921e1fb 2020-07-29)) and on https://play.rust-lang.org/

created time in 2 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 7950f012e318c065dfdf27100629e383051d14c6

Stabilize `FuseHandlers::opendir()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

John Millikin

commit sha 69bbcd45e4547cb4b6ccd559149c8f2e2cb53e53

Stabilize `FuseHandlers::readlink()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

John Millikin

commit sha 08f2d8bcad0d446ad932d034daa4a39fbc124792

Stabilize `FuseHandlers::release()` and `FuseHandlers::releasedir()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 3 months

push eventjmillikin/rust-fuse

John Millikin

commit sha cb26cf87a424b5293e97800808f328bf24af43dc

Stabilize `FuseHandlers::forget()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 3 months

push eventjmillikin/rust-fuse

John Millikin

commit sha a5f3f88f23435a4040c1ff9f8d7460e05ec9ce75

Stabilize `FuseHandlers::read()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 3 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 37d89b42fd5a42e27867be9c460ab2a3dbf69621

Stabilize `FuseHandlers::open()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 3 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 8cc59b5b84d3d3098cd707a99806a850aa3c26fb

Stabilize `OpenRequest` and `OpenResponse`. issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

John Millikin

commit sha 55266e67e6834ed4f91b3b10ded5e47469c11257

Convert `FuseInitFlags` to `bitflags_struct!()`

view details

push time in 3 months

push eventjmillikin/rust-fuse

John Millikin

commit sha eba0c7f5d9d4da4bab16161a71e4dfc99b84f01d

Make `NodeName::as_bytes()` consistent with `CStr::to_bytes()`.

view details

push time in 3 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 987f84a8c4b355181903b9cd9c3aada35b5444e9

Stabilize `protocol::LookupRequest`; introduce `NodeName` newtype. issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 3 months

push eventjmillikin/rust-fuse

John Millikin

commit sha b75d2b830189e6d971932caeeef99aaff6b7d97e

Stabilize `protocol::LookupRequest`; introduce `NodeName` newtype. issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 3 months

push eventjmillikin/rust-fuse

John Millikin

commit sha 3f2c5c4bd735e23fe0275c6f0da20a0033aa15c7

Stabilize `FuseHandlers::fuse_init()` issue: https://github.com/jmillikin/rust-fuse/issues/9

view details

push time in 3 months

delete branch jmillikin/rust-fuse

delete branch : master

delete time in 3 months

delete branch jmillikin/rust-fuse

delete branch : feature-no-libc

delete time in 3 months

more