Re: git going rust
Hi Štěpán Pressl, Because Nathan is a subversion contributor/developer, hehehe :-) Few days ago I saw a Ken Thompson presentation where someone asked him if Rust will replace C. He said he tried to develop a program in Rust and had difficulties to get it working, then sometime later with it tried it again the language already changed. I think we should take it with a grain of salt because he is biased, but he pointed out something important: Rust is a movable target. I don't know if Rust will end up replacing C, but I think we will need to learn it soon or later. BR, Alan On Sat, Sep 6, 2025 at 9:19 AM Štěpán Pressl wrote: > What's wrong with git in rust? Also, I shouldn't email it here explicitly > in the Apache's mailing list, but for the love of god, why SVN? :-) > > On Sat, Sep 6, 2025 at 3:58 AM Nathan Hartman > wrote: > > > On Fri, Sep 5, 2025 at 5:51 PM Tomek CEDRO wrote: > > > > > > > > > > > https://lore.kernel.org/git/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0...@pks.im/T/#t > > > > > > :-( > > > > > > -- > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > > There's an easy fix for that. Just switch to Subversion ;-) > > >
Re: git going rust
I honestly don't think it's terrible. I really like how explicit you can be when defining interfaces in Rust. However, I will say that I prefer C. It's stable, ubiquitous and very simple. When I've written Rust I also find there are so many functions/helpers to remember. There are sometimes so many ways to do one thing and I'm never quite certain of the "Rust" way. That being said, those issues probably go away the more you use it. It'll be interesting when the language starts to mature more. I do think it's important to support it in NuttX though! Matteo On Sat, Sep 6, 2025, 10:53 AM Alan C. Assis wrote: > Hahaha, always clever comments !!! > > Miss you Ken! I hope you are doing well !!! > > BR, > > Alan > > On Sat, Sep 6, 2025 at 10:51 AM Kenneth Pettit wrote: > > > On 9/6/25 6:41 AM, Alan C. Assis wrote: > > > I don't know if Rust will end up replacing C, but I think we will need > to > > > learn it soon or later. > > > > > > > I vote later. :) > > > > Ken >
Developing the NuttX Standard Board
Hi Everyone, We will have tomorrow morning (afternoon/evening for merians A to M) our first meeting about the NuttX Standard Board: https://www.youtube.com/live/keZAZ8GiYzI New to this subject? Ref: https://github.com/NuttX/nuttx_hardware/blob/main/Documentation/standard/index.rst Please join us to define which features we need to have in this board. BR, Alan
Re: git going rust
What's wrong with git in rust? Also, I shouldn't email it here explicitly in the Apache's mailing list, but for the love of god, why SVN? :-) On Sat, Sep 6, 2025 at 3:58 AM Nathan Hartman wrote: > On Fri, Sep 5, 2025 at 5:51 PM Tomek CEDRO wrote: > > > > > > https://lore.kernel.org/git/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0...@pks.im/T/#t > > > > :-( > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > There's an easy fix for that. Just switch to Subversion ;-) >
Re: [HELP] Feedback for MDIO bus
Hey there Mihai :-) I guess the device ops are used anyways, pointers are provided by underlying hardware, wrappers are for convenience and use ops below, I2C is more popular with various sensors so it may be okay to just have read/write calls exposed to the user, that may be easier to use but may slightly slow things down and increase memory consumption (i.e. stack + code) as opposed to using ops directly that is a bit harder but may just remove unused code parts at build time ? SPI may also be attached in DMA transfers and/or other drivers layers that just need ops and wrappers here would just slow things down? Long story short ops are for code, wrappers are for users :-P I am not sure if there are any metrics of code, stack, and speed comparison between I2C and SPI implementations with and without wrappers to answer your question in numbers. Yes probably it would be good to have this more coherent so both ops and wrappers can be used as needed. You may try to follow both paths and see what the exact difference is in your mdio implementation? I would start with implementation without wrappers and then see if wrappers are even necessary, as these ops may just be used by another layer or drivers (i.e. (r)mii) and not users directly. https://github.com/apache/nuttx/blob/master/include/nuttx/i2c/i2c_master.h https://github.com/apache/nuttx/blob/master/include/nuttx/spi/spi.h https://github.com/apache/nuttx/blob/master/drivers/i2c/i2c_driver.c https://github.com/apache/nuttx/blob/master/drivers/spi/spi_driver.c You may also take a look at implementation of these in FreeBSD and Linux and get some inspiration? https://cgit.freebsd.org/src/tree/sys/dev/iicbus https://cgit.freebsd.org/src/tree/sys/dev/spibus https://cgit.freebsd.org/src/tree/sys/dev/mdio https://cgit.freebsd.org/src/tree/sys/dev/mii Thanks :-) Tomek On Thu, Sep 4, 2025 at 9:35 AM Luchian Mihai wrote: > > Hello everyone. > > I have been tinkering around net drivers lately. I set my goal to implement > a mdio bus to add a bit of modularity to the monolithic netdevs approach > (the full ones, not the lowerhalfs). > > Currently my prototype is working although I cannot wrap my head around the > "logic" or "architecture" of the existing buses implementation, spi and i2c > to be specific. I understand both approaches, but I do not know why they > are used differently and what approach should mdio follow. > > So, to be short. Aside from the device struct specification (i2c_master_s > located in i2c_master.h and spi_dev_s in spi.h) both buses also offers > wrappers around data exchange (i2c_read, i2c_write, spi_transfer, etc) > which handles the common bus transaction logic. There is a description for > spi_transfer function which states that it is a helper function. I also see > that the spi also offers multiple dev types which may be another reason why > these two buses are used differently. > > My questions are: > > Why is the i2c bus used mainly through the "wrapper" functions (i2c_read, > i2c_write, i2c_writeread) while the spi bus prefers using the device ops > functions directly (using the provided #defines). > > Which of these two approaches would you recommend for a mdio bus, or which > should be the prefered approach in general? > > Any other feedback or ideas are also welcomed. What would you like to see > in a mdio bus implementation for NuttX? > > Cheers, > Mihai -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: git going rust
Yeah, I understand people might not like it, and I respect that. I would also encourage support it in NuttX. Ludovic Vanasse ludovicvana...@gmail.com On Sat, Sep 6, 2025 at 11:11 AM Matteo Golin wrote: > I honestly don't think it's terrible. I really like how explicit you can be > when defining interfaces in Rust. However, I will say that I prefer C. It's > stable, ubiquitous and very simple. When I've written Rust I also find > there are so many functions/helpers to remember. There are sometimes so > many ways to do one thing and I'm never quite certain of the "Rust" way. > > That being said, those issues probably go away the more you use it. It'll > be interesting when the language starts to mature more. I do think it's > important to support it in NuttX though! > > Matteo > > On Sat, Sep 6, 2025, 10:53 AM Alan C. Assis wrote: > > > Hahaha, always clever comments !!! > > > > Miss you Ken! I hope you are doing well !!! > > > > BR, > > > > Alan > > > > On Sat, Sep 6, 2025 at 10:51 AM Kenneth Pettit > wrote: > > > > > On 9/6/25 6:41 AM, Alan C. Assis wrote: > > > > I don't know if Rust will end up replacing C, but I think we will > need > > to > > > > learn it soon or later. > > > > > > > > > > I vote later. :) > > > > > > Ken > > >
Re: git going rust
On 2025-09-06 11:11:03, Matteo Golin wrote: > I honestly don't think it's terrible. Rust is good idea but with terrible execution. Which results in code being safely unreadable ;) signature.asc Description: PGP signature
