A richer tag system

[japaric]

#1 originally proposed using just three labels, Arduino, OpenWRT and RPi, to categorize issues. But @nastevens proposed using a richer tag system. Also check my comment about grouping tags in categories. The questions are:

• Should we adopt a richer tag system for issues? Also for the list of curated crates? (I'm in favor of both). What about tags for documentation? (I prefer bigger categories like "micro-controller" over tags in this particular case)
• Should we group our tags in categories like rust-lang/rust does? e.g. A-x86, A-avr, A-arm, etc. where A stands for Architecture.
• What tags should we start with? We don't have to come up with all of them right now. But if we are going to use the categories system proposed above, we should try to come up with as many categories as early as possible, I think.
• Extra idea of mine: Should we recommend a set of tags for crates on crates.io? Like: "if your crate only works for a specific architecture, use one of these tags: arm, avr, x86, etc.". Another; "if your crate doesn't use heap allocation then use the no-heap tag", etc.

[thejpster]

So, my view on embedded development (and while I've done this sort of thing professionally for the past 12 years, I'm aware that I'm still a relative newcomer) is this. For me, the difference between embedded software and 'non-embedded' software comes down to privilege. Software that is 'non-embedded' is low privilege - that is, it is isolated in its own virtual memory space, it's limited as to what 'damage' it can do and it has to rely on services (such as the user-facing APIs exposed by drivers) provided by the OS. Embedded applications are generally high privilege - they have access to the physical address space of the processor (whether memory mapped in to their virtual address space, or because there is no MMU), they can cause more 'damage' (i.e. cause a reboot) and they have a limited set of services available. This isn't necessarily a binary either/or - if I'm developing a modem using an RTOS like Nucleus, then I don't have an MMU but I do have a Berkeley socket API (of sorts...) and a filesystem API. But is that OS functionality supported by libstd? No. So it's more embedded that non-embedded. If I was writing a kernel driver for Linux I would consider that embedded development - I don't have access to the same user-space syscalls and I can do bad things with the hardware from a kernel driver. If I'm on a Raspberry Pi, then it's probably not embedded development - even if there's no screen and keyboard connected. But if I'm writing a Neopixel library for the Pi by mapping the DMA registers into my application address space (using /dev/mem), such that the code can only be executed as root and I have direct access to the hardware, then it's probably veering towards embedded, even if the standard library is available.

I think the other comment I'd want to make is to echo other calls I've seen to try and stay away from trade names like Arduino, and try and keep these things generic.

So, I'm going to propose something like:

root - this code is user-space, but it runs as root and uses tricks like mapping /dev/mem to access the hardware. The standard library is available, but we need to be aware we have the ability to do more damage than a regular user-space program.

no_std - we're basically saying this is either not user-space, or we're on an OS with an unsupported user-space. This will usually be 'root' but not necessarily (maybe, I don't know, FreeBSD on MIPS, or some other platform that's not even Tier 3).

kernel_mode - this code requires kernel mode. That's not to say it necessarily requires a kernel - it might just run on bare metal - but it won't run as a user-space application because it expects access to hardware registers. This implies 'no_std'.

bare_metal - this code will only run without any form of OS present. It starts from the reset vector and is doing it's own C Startup (humm, we should rename that). This implies 'kernel_mode'.

I'm happy to accept a no_heap tag, but I've found that in practice pools allocators can work even on low memory platforms (as a concrete example, the CSR BlueCore 5 has about 24 kibiwords of SRAM and the stack still runs a pretty advanced pools allocator). I guess it depends on your definition of "low memory". But, I can see how it might be useful to let users of your crate know that there isn't any heap usage, even if they have a heap available.

Finally, just a quick thought on architectures. To the extent that is matters, I'd propose that we follow whatever conventions LLVM use to describe platforms and architectures. I guess I mean that 'ARM' as a generic term isn't that useful a distinction when the code generation and intrinsics for an ARM7 differ so much to those for a Cortex-A53. If you mean 'arm' as in the LLVM archtype (as opposed to aarch64 or or thumb), then that's fine.

[nastevens]

Interestingly, #12 seems to already be flushing out a number of tags. I propose that we let that survey run its course and use that to inform any decisions we make here.

I've put out a request to the community to help flesh out that list on Twitter and Reddit. Other places we should perhaps solicit?

[japaric]

Other places we should perhaps solicit?

I'm late but the Rust users forum is a good place. I've also added links to our surveys to the gitter and IRC channels.

[jamesmunns]

Do we feel like this issue is still valuable? Should this tie into the "better Cargo" story? Maybe CC @therealprof?

Otherwise I would propose that we close this issue, and open up a new one that better captures the current state of things.

Marking this for a cleanup sweep. If we would like this to stay open, please provide an update to what this issue should be focused on.

[therealprof]

I think the specific architecture tags might be a bit of overkill since our ecosystem nowadays is either very MCU specific or really generic. Just improving the crate story would totally work for me.

[jamesmunns]

@therealprof do you have anything we can link to here about the things you discussed with the crates.io team?

[therealprof]

@jamesmunns Don't have anything, it's all off the record. But I'll follow up with them...

[therealprof]

@jamesmunns Actually reading through the history of this issue, this is not something I discussed with the team at all. ;)

[japaric]

This was about changing the labels used in this repository but the issue is out of date because things have changed since then so closing.