profile
viewpoint
Xavier Bestel bestouff Grenoble, France

bestouff/genext2fs 19

genext2fs - ext2 filesystem generator for embedded systems

bestouff/pktparse-rs 12

Parse various network packets using nom

bestouff/catmark 9

CatMark - Markdown(CommonMark) printer for the terminal

bestouff/e2fslibs-sys 1

Rust FFI bindings for e2fslibs

bestouff/bitpacking 0

SIMD algorithms for integer compression via bitpacking. This crate is a port of a C library called simdcomp.

bestouff/call-recorder-for-android 0

call-recorder-for-android fork

bestouff/chipdocs 0

Documentation site for NTC chip. All current markdown files are in source/includes

bestouff/diesel 0

A safe, extensible ORM and Query Builder for Rust

bestouff/distributions 0

NodeSource Node.js Binary Distributions

bestouff/documentation 0

Official documentation for the Raspberry Pi

issue commentnextcloud/android

Conflict promt on Auto Upload with "Overwrite remote version" checked

For me it happens for new files, and doing your manipulations doesn't change the behavior.

jeroen7s

comment created time in 6 days

issue commentnextcloud/android

Conflict promt on Auto Upload with "Overwrite remote version" checked

Failed uploads are piling up. If anyone has a workaround in the meantime please share !

jeroen7s

comment created time in 9 days

issue commentrust-windowing/winit

`get_current_monitor()` panics on Wayland.

Ok ok, I get it :)

icefoxen

comment created time in a month

issue commentrust-windowing/winit

`get_current_monitor()` panics on Wayland.

I'd say this calls for a third enum variant.

icefoxen

comment created time in a month

pull request commentrust-lang/rfcs

RFC: Named arguments

fn scale(.point Point(x, y): Point, .by coeff u64) -> Point {
    Point(coeff * x, coeff * y)
}

shouldn't that read instead :

fn scale(.point Point(x, y): Point, .by coeff: u64) -> Point {
    Point(coeff * x, coeff * y)
}

?

Aloso

comment created time in 2 months

issue commentbytebeamio/rumqtt

Please transfer ownership of old rumqtt repo

Oh my bad, I thought this bug was opened on the old repo. No news on that front then.

bestouff

comment created time in 2 months

issue commentbytebeamio/rumqtt

Please transfer ownership of old rumqtt repo

Apparently things happened to this repo. Would it be possible to know what ?

bestouff

comment created time in 2 months

Pull request review commentrust-lang/rfcs

Add Drop::poll_drop_ready for asynchronous destructors

+- Feature Name: `poll_drop_ready`+- Start Date: 2020-07-17+- 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++Add a `poll_drop_ready` method to `Drop`, and change the drop glue in async+contexts to call this before calling `drop`. This will allow users to perform+async operations during destructors when they are called in an async context.++# Motivation+[motivation]: #motivation++Rust encourages an idiom which originated in C++ called "Resource Acquisition+Is Initialization," or "RAII." This name is very unclear, but what it means is+that objects in Rust can be used to represent program state and IO resources,+which clean themselves up when they go out of scope and their destructors run.+As Yehuda Katz wrote in 2014 [Rust means never having to close a+socket.][close-a-socket]++However, there is no way to perform a *nonblocking* operation inside a+destructor today without just blocking the thread the destructor is running on. +This is because destructors have no way to yield control, allowing the executor+to run other tasks until this operation is ready to continue. This means that+the performance advantages of our nonblocking and concurrent Future constructs+do not apply to destructor clean up code. It would be preferable for these+constructs to be able to use nonblocking IO when they are used in an async+context.++I'll describe a few concrete examples.++## Flushing and buffered writers++It's fairly common to create `Write` types which perform flush, fsync or even+writes in their destructor. For types which are intended to perform+asynchronous writes, its not possible to do this as a part of the destructor+code.++For example, the std `BufWriter` type is designed to take a series of small+writes and perform a smaller number of large writes at once. It possibly+performs this in its destructor, to guarantee that all writes made to it+ultimately go through to the underlying `Write` type. A similar construct for+async code would have to either: a) flush in a blocking manner, b) spawn a +new task onto some sort of executor to perform the flush, c) not flush at all+in the destructor, opening the user up to missed writes when they forget to+flush before dropping.++The [`BufWriter` type in `async-std`][bufwriter], for example, currently does+not flush in its destructor because it cannot do so asynchronously. With+`poll_drop_ready`, it would be able to perform an asynchronous flush as a part+of its destructor code.++## Types can which close asynchronously++Types which guard file descriptors usually close the file descriptor when they+are dropped. Some interfaces, like io-uring on Linux, allow closing file+descriptors to be performed asynchronously.  This cannot be performed by the+destructor, because it cannot yield control.++## Types which update internal program state in their destructors++It's not only IO that could be made non-blocking. Some types update state that+is internal to the program when they are dropped, using types like mutexes and+channels. If these programs want to use the nonblocking version of these+constructs, so that only this task waits for the channel to have room or the+mutex to be free, this is not currently possible in their destructor. Instead,+they have to block the entire thread.++## Scope guards++One pattern used in Rust is the "scope guard" - a guard which cleans up state+after user code has executed. There are important caveats to implementing this+pattern safely in a public API (which are better covered in discussions of+memory leaks and destructors), but it can be done safely by passing a reference+to the scope guard to a higher order function. In these examples, the scope+guard implements a destructor which performs the clean up. This way, even if the+client code panics and unwinds, the clean up gets performed. That clean up+cannot be asynchronous today, because the destructor has no way to yield+control.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++The `Drop` trait gains one new method, with a default implementation:++```rust+trait Drop {+    fn drop(&mut self);++    fn poll_drop_ready(&mut self, cx: &mut Context<'_>) -> Poll<()> {+        Poll::Ready(())+    }+}+```++Like `Drop::drop`, it would not be possible to call `poll_drop_ready` on a+type (users should use `mem::poll_drop_ready` discussed below instead).++When a value is dropped inside of an async context (that is, an async function+or block), it's `poll_drop_ready` method will be called repeatedly until it+returns `Poll::Ready(())`. Then, its `drop` method will be called. This way,+users can perform (or prepare to perform) nonblocking operations during+destructors when they are called in an async context.++It's important to note, however, that `poll_drop_ready` may be called even+after it has returned `Poll::Ready(())`. This is different from the `drop`+method, which is generally guaranteed to be called only once. Users+implementing `poll_drop_ready` should take care to ensure that it has "fuse"+semantics - that once it returns `Ready(())`, it continues to return that value+thereafter.++These additional APIs are also added to the `std::mem` module:++```rust+// an empty async function+async fn drop_async<T>(to_drop: T) { }++fn poll_drop_ready<T>(&mut self, cx: &mut Context<'_>) -> Poll<()>+    where T: ?Sized+{+    // implemented through a lang item+}+```++The `drop_async` function is analogous to the `drop` function, and is also+added to the prelude as well. This function drops the value in an async+context, guaranteeing that its `poll_drop_ready` method will be called.++The `poll_drop_ready` function calls this value's "drop ready glue" - it calls+`poll_drop_ready` on this value and also on all of its fields, recursively. The+exact ordering and semantics of this glue are specified in the reference+section.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++## Guarantees about when `poll_drop_ready` is called++In general, users cannot assume that `poll_drop_ready` will ever be called,+just as they cannot assume that destructors will run at all. However, they can+assume less about `poll_drop_ready` than they can about `drop`, and that should+be noted.++In particular, users cannot safely assume that their values will be dropped in+an async context, regardless of how they are intended to be used. It's this+easy to supress the `poll_drop_ready` call of a value:++```rust+async fn ignore_poll_drop_ready<T>(x: T) {+    // by passing `x` to `drop`, a non-async context, `poll_drop_ready` is+    // never called when dropping `x`.+    drop(x);+}+```++However, we do guarantee that values dropped in an async context *will* have+`poll_drop_ready` called, and we even guarantee the drop order between

Would it be possible to explicitly add that poll_drop_ready may not be called, but when it's called it's in a loop at least until it returns Poll::Ready(()) ?
(Yes it's been already said above, but I feel it should also be in the "guarantees" section)

withoutboats

comment created time in 2 months

issue openedlinux-sunxi/sunxi-tools

FEL from 1.4.2 fails on NextThingCo C.H.I.P.

See Thore-Krug/Flash-CHIP#21 for more details, at the end of the thread they confirm 1.4.1 fixes the issue.

created time in 3 months

created tagbestouff/genext2fs

tagv1.5.0

genext2fs - ext2 filesystem generator for embedded systems

created time in 3 months

issue closedbestouff/genext2fs

wrong filename if tarball entry is exactly 100 characters long

steps to reproduce:

$ mkdir test
$ touch test/0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01
$ tar -C test -cf test.tar .
$ ./genext2fs -B 1024 -N 17 -b 200 -a - -f -o Linux test.img < test.tar
$ sudo mount test.img /mnt
$ ls -lha /mnt
drwxr-xr-x  3 root  root  1.0K Jan  1  1970 .
drwxr-xr-x 25 root  root  4.0K Jun 12 16:28 ..
-rw-r--r--  1 josch josch    0 Jun 25 13:57 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef010000644
drwx------  2 root  root   16K Jan  1  1970 lost+found

As you can see, the filename has "0000644" appended at the end.

closed time in 3 months

josch

issue commentbestouff/genext2fs

wrong filename if tarball entry is exactly 100 characters long

Closed by #24

josch

comment created time in 3 months

push eventbestouff/genext2fs

Johannes 'josch' Schauer

commit sha 4f6e7dbe36bdf6dbabeeb3dc58960158bc1eb989

fix support for hardlinks in tarballs

view details

Johannes 'josch' Schauer

commit sha 761e2a73a0784274e9b4853927f578d0a5b59c3b

fix broken filename if path is exactly 100 characters long

view details

Xavier Bestel

commit sha 474111097321f03de9e009aa9f7d4a8948e310b2

Merge pull request #24 from josch/tarhardlinks fix support for hardlinks in tarballs

view details

push time in 3 months

PR merged bestouff/genext2fs

fix support for hardlinks in tarballs

closes #21

+6 -4

1 comment

2 changed files

josch

pr closed time in 3 months

issue closedbestouff/genext2fs

no support for hardlinks in tarballs

steps to reproduce:

$ mkdir test
$ echo foo > test/foo
$ ln test/foo test/bar
$ tar -C test -cf test.tar .
$ tar tvf test.tar
drwxr-xr-x josch/josch       0 2020-06-24 15:37 ./
-rw-r--r-- josch/josch       4 2020-06-24 15:37 ./bar
hrw-r--r-- josch/josch       0 2020-06-24 15:37 ./foo link to ./bar
$ ./genext2fs -B 1024 -N 17 -b 200 -a test.tar -f -o Linux -q test.img
$ sudo mount test.img /mnt
$ ls -lha /mnt
ls: cannot access '/mnt/foo': Structure needs cleaning
total 23K
drwxr-xr-x  4 root root 1.0K Jan  1  1970 .
drwxr-xr-x 25 root root 4.0K Jun 12 16:28 ..
-rw-------  1 root root    4 Jun 24 15:37 bar
??????????  ? ?    ?       ?            ? foo
drwx------  2 root root  16K Jan  1  1970 lost+found
$ head /mnt/foo                                                                                                                                                                /tmp/genext2fs
head: cannot open '/mnt/foo' for reading: Structure needs cleaning

If hardlinks from tarballs will not be supported or until they are supported, genext2fs should at least throw an error when the tarball contains them.

closed time in 3 months

josch

issue closedbestouff/genext2fs

Issue with symlinks where target is exactly 60 characters

When a symlink target path is exactly 60 characters long, the final character is being truncated in the generated image.

For example, here is a symlink in my source directory:

/tmp/genimage/root/etc/ssl/certs/ca-cert-QuoVadis_Root_CA_3_G3.pem -> /usr/share/ca-certificates/mozilla/QuoVadis_Root_CA_3_G3.crt

Looking at the resulting image (mounted at /mnt), the final "t" is missing:

/mnt/etc/ssl/certs/ca-cert-QuoVadis_Root_CA_1_G3.pem -> /usr/share/ca-certificates/mozilla/QuoVadis_Root_CA_1_G3.cr

closed time in 3 months

ab3fx

issue commentbestouff/genext2fs

Issue with symlinks where target is exactly 60 characters

Good job @josch (as usual). Closing.

ab3fx

comment created time in 3 months

issue closedbestouff/genext2fs

Please support reading tarballs from stdin.

Thanks for accepting the libarchive pull request!

Next I'd like to be able to read tarballs from standard input. I wanted to use this issue to discuss how the interface for that should best look like. The major difference is, that when the data comes from stdin, it cannot be read twice to automatically determine how many inodes to allocate. In principle, the caller can do their own inode computations and then call genext2fs with the right -N argument. But maybe it makes sense for the caller to only supply the size -b and have the number of inodes be chosen by a heuristic if the input comes from stdin? After all, when creating an ext2 filesystem, I also only specify its size and I don't have to specify the number of inodes.

What do you think?

closed time in 3 months

josch

issue commentbestouff/genext2fs

Please support reading tarballs from stdin.

Implemented by #22

josch

comment created time in 3 months

issue commentbestouff/genext2fs

The -d, -D and -a options do not allow paths containing a colon or all unicode chars where their encoding contains 0x3A

Another problem is, that strchr and strrchr operate on bytes and not on characters. This means, that all unicode characters containing 0x3A are also not supported in input paths -- that's a lot of characters.

I don't think so. IIRC utf-8 is very well engineered, 7-bits characters are never part of a multibytes char. In fact each char in isolation can tell you if it's standalone or part of a multibytes char.
But yes, it should be documented and probably "escapable" somehow.

josch

comment created time in 3 months

push eventbestouff/genext2fs

Johannes 'josch' Schauer

commit sha 9fd4447db54188e79d432dd6ced2a5fd9daed231

read from stdin if filename equals '-' for -D and -a options

view details

Xavier Bestel

commit sha ce4de57744fb5b5edeba7d042686e04c35fc6428

Merge pull request #22 from josch/fromstdin read from stdin if filename equals '-' for -D and -a options

view details

push time in 3 months

PR merged bestouff/genext2fs

read from stdin if filename equals '-' for -D and -a options

This pull request adds support for reading the device table or the input tarball from stdin. Only one input can come from stdin. Any input that comes from stdin does not contribute to the computation of stats. I amended the tests such that those tests involving the device table or tarballs are executed twice: once with passing the filename and once with passing - and reading from standard input. The output of either must be the same.

+72 -20

2 comments

4 changed files

josch

pr closed time in 3 months

pull request commentbestouff/genext2fs

read from stdin if filename equals '-' for -D and -a options

Looks good. Could you add some documentation about this, and the fact that calculations are wrong ? And maybe print a warning in this case ?

josch

comment created time in 3 months

push eventbestouff/genext2fs

Xavier Bestel

commit sha 41b19b452c0dada0cbcc6021b987f9933a7bd5d8

new email address

view details

push time in 3 months

issue commentbestouff/genext2fs

Please support reading tarballs from stdin.

Is that something you really want for the next release ?

josch

comment created time in 3 months

issue commentbestouff/genext2fs

Please support reading tarballs from stdin.

I think I should do a more general input arguments handling, where any of them can be stdin - but then automatic sizes calculations are off the table.

josch

comment created time in 3 months

pull request commentbestouff/genext2fs

allow reading from tarball on stdin

Thank you I started to be a bit lost in the tar formats :)

josch

comment created time in 3 months

PR merged bestouff/genext2fs

allow reading from tarball on stdin

This pull request fixes https://github.com/bestouff/genext2fs/issues/10

The user interface is changed like this: when no input is given via -d or -D, then genext2fs will open standard input and try reading a tarball from it.

By default, genext2fs tries to create the minimum number of inodes by reading the input twice. This is of course not possible when the input is read from stdin. Thus, the user has to supply the number of inodes manually. To not make this too painful, the new special value 0 got introduced for the -N option which means: compute inode number automatically from the blocksize and number of blocks.

With this commit I can successfully create a full Debian system image like this:

./genext2fs -b 144000 -N 0 disk.img < chroot.tar

This is a work in progress. What do you think?

+240 -20

13 comments

5 changed files

josch

pr closed time in 3 months

push eventbestouff/genext2fs

Johannes 'josch' Schauer

commit sha 0d2a1320d75ea347c8f1a226493a2a472247a419

add support for reading tarballs with libarchive

view details

Xavier Bestel

commit sha a1b9c6919de2bb481c5a592dc0e01ad090f87306

Merge pull request #11 from josch/master allow reading from tarball on stdin

view details

push time in 3 months

issue closedbestouff/genext2fs

Support for converting tarballs to ext2

Hi,

would you accept a pull request allowing genext2fs to read a tarball (for example by using libarchive) and turn it into an ext2 image?

Even non-root users can easily create, store and manipulate tarballs containing files, directories and device nodes with arbitrary ownership, permissions, timestamps and other attributes. The interface could be as simple as:

$ genext2fs < rootfs.tar > rootfs.img

What do you think?

closed time in 3 months

josch

issue openedhuhu/rust-search-extension

Remind me of "rs"

I keep forgetting I have to type rs to activate the extension (please don't laugh), and each time I have to go to the website, realize it's not written anywhere here (and doesn't appear in the featured videos), then go to github and find the information.

So could you please add something like "type rs to activate rust search" prominently on the website and in the sort-of "about box" which appears when I click on the rust icon next to the search bar ?

created time in 3 months

issue commentSpaceVim/SpaceVim

Updating Plugins Fails

** for people with broken installation after SPUpdate ** here's a command that worked for me:

# cd ~/.SpaceVim
# git reset --hard
PeterDing

comment created time in 3 months

more