After trial and error, i.e. brute force going through crc crate algorithms, I can say that CRC32_32_ISO_HDLC is the correct variant for ZMODEM 32-bit transfers, i.e. cipher can be acquired by:

const CRC32: Crc<u32> = Crc::<u32>::new(&CRC_32_ISO_HDLC);

It is better to declare like this so that it gets compiled into .rodata and not initialized at run-time.

Pretty easy way to implement this strategy: avoid using Vec to the extremes. It is quite common in Rust programs that there’s tons of Vec instances, while in reality most of them are fixed arrays on their usage patterns. In addition heapless provides pretty nice set of structures for common tasks with a fixed amount data space.

I really like this heapless. It sort of helps to implement my strategy for developing Rust programs:

1.Maximize no_std surface. 2 Minimize heap allocations.

It is easier to see then the hot zones where the program actually dynamically grows for a good reason, similarly as with unsafe blocks it is easy to the red zones for memory errors. This helps a lot with availability and protection against denial-of-service (DoS) attacks.

So to summarize I don’t split Rust program in my mind just to “unsafe” and “safe” but instead I split it “unsafe”, “static” and “dynamic”, or along the lines.

@vbabka DoD for me when writing patches or reviewing them is that any code change should leave places cleaner than they were, even if minuscule amount, or at least not have negative impact.

really like this fsmetry crate (also no_std):

fsmentry::dsl! {
    #[derive(Debug)]
    pub Mode {
        WaitingInput -> WaitingCommand -> WaitingInput;
        WaitingCommand -> SendingFile -> WaitingInput;
        WaitingCommand -> ReceivingFile -> WaitingInput;
        WaitingCommand -> Exit;
    }
}

I use it manage life-cycle in my small serial port tool tior. I also have some #zmodem code together but it is apparently much bigger leap to implement the #cli interface than it is to implement the protocol. I had to take some time to refactor existing code (e.g. to put FSM in place) and now I’m doing file path auto-completing interface for sending and receiving files with zmodem.

For the text input I’m going to use inquire.

I guess the definition of feature complete for 0.1 version is fully working zmodem transfers and known bugs have been fixed. Right now there is a single known bug: https://github.com/jarkkojs/tior/issues/1.

#tior #fsmentry #inquire #rustlang

in zmodem protocol there's lot of places where you could "low-barrier" modernize it and i think i'm going after that. like even though there is binary transfer the receiver responds always with hex string for ack's. so that doubles amount of bandwidth for no good.

I've started to use #himalaya as my email client. I switched from mutt to aerc year ago but it has not worked for my intuition but this actually feels a fresh take on #email.

What makes it a fresh take is in my opinion how it reduces the amount of context switching when you have email sort of integrated to the shell. In mutt you can do a lot without leaving the client but this sort of takes away the whole issue and gives full shell access.

@monsieuricon awesome thanks

@josh actually that sort of mock cross compilation toolchain would be pretty useful as a tool

@josh Or probably would have some intermediate presentation for the graph that I would later on render as dot file.

@josh that is correct. on plus side it is still built on top of fairly primitive blocks so thought that it might be good to mention anyhow.

If I really had to do this. I would simply create a fake cross compile toolchain let's say CROSS_COMPILE=" dot-linux-". For all tools I would implement either take no other action but returns success but those relevant to the graph I'd update the dot file.

That is at least universal across toolchains (GCC, LLVM) and requires zero changes to the makefiles, and you'd only had to implement it once.

@tommythorn probably few years from now and RISC-V is also EFI/ACPI across the spectrum, which higher-level payload already. standards, despite being complex, are stable and they continue to exist. so they are in many ways better than Rust crates to some degree. Nobody gets never bored maintaining them and their reference implementations.

@tommythorn not sure if embassy would be the tool of that decades taking job if i was into that. i can prove this to myself just by looking how much stuff in u-boot there is just to wake up dram controllers etc. :-) does not sound too productive work for me

I'll try that crate to see if it is working at all with my RISC-V board...

@suihkulokki well it is literal fact that smodem protocol is still the king of serial link albeit quite unuseful. the same idea as in smodem protocol could be extended to the direction that instead of chatting with the sysop you have a TTY session while file is transferring in the background. so totally modern stuff

lol priceless clip art from 90s and afaik the place is still mainly a computer repair shop in vantaa finland. but they did smodem. pretty awkward piece of finnish computing history tbh :-) https://www.arisoft.fi/smurf/ohje.htm

software products of finnish software company arisoft. it is fun observation that the whole serial link thing that they had on-going is generation over what people use today when they connect TTL-USB-cable. Arisoft had a MS-DOS software in the early 90s that made possible to "smurf" your way in through the serial and have simultaneous file transfer at the same time. multitasking is imho the future.

so when i look at this web page i'm literally not looking into the past but to one generation ahead in the hopefully not so distant future.

#zmodem #smodem #bbs #serial #tty

@monsieuricon is there any plans to have some tool level interaction with kernel bugzilla? that is sort of forum that gets easily disregarded because LKML is the top priority. with better tooling it would be easier to provide better service. right now the bugzilla feels sort of separate island where you have to take a boat to visit and do your business, and then come back to the mainland.

should start using patchwork again for a test run. had totally forgotten its existence not to disregard its usefulness. since i use b4 already with lore, i'll test run this for a some patch set under review, thanks for reminder :-)

so the way to differentiate from other offerings here is for me to just not make generic xyzmodem crate but just focus on fluent zmodem binary transmit. and for further support disregard any other features except binary link level stuff that makes sense to modern SBC's. still makes the interface just generic enough to later on support SMODEM style multiplexing where the bandwidth can be shared with file transfers and an interactive session.

so the scope is anything that helps with the transport layer and not carry any corpse protocols.

just using this as a tool to put some notes as this thing keeps developing :-) i'll try to get zcbin first work in my tior serial tool concept (GPL2) and later on detach the protocol part to a MIT or similar licensed crate.

i guess i could create a completely new crate to the crate ecosystem called rmodem with initially just with ZCBIN implementation but sort of BufReader/Writer approach towards integration.