How to start/continue developing an abstraction for a subsystem?

[newchild]

Hello,

sorry if this is the wrong place to ask, in this case please tell me if I should ask this on zulip.

I just have a generic question:

Say I want to use the PHY subsystem (https://docs.kernel.org/networking/phy.html) in a rust linux driver.

From what I understood for the development process the first step would be to check if there already is an abstraction. How do I find out if there is already an abstraction (I am really new, maybe I missed some documentation).

If there isn't already, what would be the steps to start this? Would I need to ask the LKML C Subsystem maintainer, do I need to request to work on this somehow?

In regards to that:
Maybe a simple "How to get started & Overview of developing new/existing bindings" document would help to answer those questions? Maybe it already exists and I just missed it?

Kind Regards

[ojeda]

sorry if this is the wrong place to ask, in this case please tell me if I should ask this on zulip.

No worries! In general, yeah, please ask questions in Zulip -- please see:

https://rust-for-linux.com/contact#zulip-chat

From what I understood for the development process the first step would be to check if there already is an abstraction. How do I find out if there is already an abstraction (I am really new, maybe I missed some documentation).

Currently you would take a look into rust/kernel/* and see what is there, possibly via https://rust.docs.kernel.org/kernel/.

I would also recommend searching in Lore, i.e. in the mailing list: https://rust-for-linux.com/contact#mailing-list, as well as asking in Zulip to double-check, since even if it is not there merged, it may be in the pipeline or someone may be working on it.

If there isn't already, what would be the steps to start this? Would I need to ask the LKML C Subsystem maintainer, do I need to request to work on this somehow?

Maybe a simple "How to get started & Overview of developing new/existing bindings" document would help to answer those questions? Maybe it already exists and I just missed it?

If you have not seen it, please check https://rust-for-linux.com/contributing -- there is a section on submitting new abstractions and another on changes to existing ones.

If you are looking at PHY, there are a couple drivers in-tree -- Cc @fujita @tgross35.

I hope that helps!

[newchild]

Thank you for the fast and comprehensive answer :)

sorry if this is the wrong place to ask, in this case please tell me if I should ask this on zulip.

No worries! In general, yeah, please ask questions in Zulip -- please see:

https://rust-for-linux.com/contact#zulip-chat

Thank you, in the future I will use this communication channel.

From what I understood for the development process the first step would be to check if there already is an abstraction. How do I find out if there is already an abstraction (I am really new, maybe I missed some documentation).

Currently you would take a look into rust/kernel/* and see what is there, possibly via https://rust.docs.kernel.org/kernel/.

Thank you for this link. Maybe I am "too dumb" but this link especially seems somewhat hidden. If I go to https://rust-for-linux.com/ it seem it only appears somewhat down the sidebar. But I guess this is some bikeshedding or should be reported via zulip.

If there isn't already, what would be the steps to start this? Would I need to ask the LKML C Subsystem maintainer, do I need to request to work on this somehow?
Maybe a simple "How to get started & Overview of developing new/existing bindings" document would help to answer those questions? Maybe it already exists and I just missed it?

If you have not seen it, please check https://rust-for-linux.com/contributing -- there is a section on submitting new abstractions and another on changes to existing ones.

Thank you, that in contrast was completely my fault, i somehow skipped this completely as I confused it for a checklist for things to do before actually merge requesting. My bad!

If you are looking at PHY, there are a couple drivers in-tree -- Cc @fujita @tgross35.

Thanks but this was a completely hypothetical example, as I was working on a ti phy integration for work in parallel, but in c :( ;)

I actually wanted to start with some kernel work, but all "low level" first issues were already taken, so I thought some review/development of existing (c) subsystems would be the smartest next step.

Really thank you for your effort again! :)

I will close this issue then!

Best regards
Fabian