lin-bus / linux-lin

Linux kernel LIN bus support implemented as TTY line discipline for generic UART conrollers, documentation https://github.com/lin-bus/linux-lin/wiki, based on https://github.com/lin-bus/linux-lin/wiki/sllin-rtlws14-paper.pdf, more CAN related projects http://canbus.pages.fel.cvut.cz/
https://github.com/lin-bus/linux-lin/wiki
38 stars 26 forks source link

Setup mainline/ustream repo which is easy to find #4

Open ppisa opened 2 years ago

ppisa commented 2 years ago

To all slLIN users,

the project mainline/upstream is hard to be found which results in annoyance, redundant solving of the already solved issues and other time waste. If there should be chance for acceptance into mainline Linux kernel we need consolidation and maintainers backup.

Background

I was one of initiators and coordinator of the initial Linux UART LIN bus solution slLIN. Idea about SocketCan API comes from Oliver Hartkopp (@hartkopp), one of initiators of the Linux SocketCAN. The work of me and @lisovy at Czech Technical Univesity in Prague has been initially funded by Volkswagen Research. I have continued maintainer-ship in my spare time later with support of my company PiKRON colleagues who designed original HW etc... Project has been used and some maintenance contributed by E4T (Voklswagen subsidiary now). Original repo http://rtime.felk.cvut.cz/gitweb/linux-lin.git is hard to find and the server was taken away from our faculty when original IIG group moved away and my will to continue cooperation with it has been betrayed hard way by doctor Michal Sojka in start of 2017 year so it is not my preferable mainline now. There are many forks on GitHub without clean upstream and because probably nobody from us has funded contract to maintain the project and contribute mostly on voluntarily base or when somebody has concrete use case, the project organization and finding latest version is hard and forks lack synchronization.

Proposed solution

I have setup organization https://github.com/lin-bus

I invited @trainman419, @knezicm, @kbader94, @lisovy as co-owners to ensure backup and chance to integrate changes. It would be great if we setup merge requests practice targeting this project. I suggest to to consider keeping compatability with 4.4 kernel by ifdefs for now due to use of this kernel in Civil Infrastructure Platform.

To @trainman419, please, move your linux-lin project under https://github.com/lin-bus organization. Then fork it again to your account. That way all other forks would point users to search for updates and help in the community project where is larger chance that some of volunteers finds time.

To @kbader94, please, setup your linux-lin repo as the fork of the lin-bus upstream repo, prepare merge request for README.md and other changes. We can discuss them.

In the long term, we can try to enhance Linux mainline UART to support setup of Rx FIFO threshold level general way. I have idea, but there has to be declared real user base interest and demand to TTY maintainers the first.

It would worth to fork https://github.com/linux-can/can-utils and prepare merger request adding option to select LIN discipline in slcan_attach.c.

We should try to register discipline numbers in mainline. There would be problem with LIN_MASTER and LIN_SLAVE identifiers (sic) so we should think about alternatives as LIN_COORDINATOR, LIN_TARGETONLY or something other which pass, suggested leader and follower is the mess and who knows when leader becomes offending again.

There is interest in LIN bus in NuttX RTOS community as well. We can coordinate effort.

Thanks for your time and attempts to move project forward,

Pavel Pisa

trainman419 commented 2 years ago

Ok; I've transferred ownership of this repo to the lin-bus organization. Github automatically sets up a redirect from https://github.com/trainman419/linux-lin to this repository, so I don't think I need to set a new fork; old links will be redirected automatically.

kbader94 commented 2 years ago

To @kbader94, please, setup your linux-lin repo as the fork of the lin-bus upstream repo, prepare merge request for README.md and other changes. We can discuss them.

I've setup my repo as a fork and created a branch with some preliminary changes that made it work with newer kernel versions. I still need to find out exactly which kernel version it changes and update it so it doesn't destroy support for older versions before I make a PR. I appreciate you offering me the opportunity to help contribute to this awesome project. I look forward to working with you all and hope you and others find my contributions useful!

kbader94 commented 2 years ago

I like the idea of including additional repos, Forking can-utils is a great idea and not much work. I also think there's merit in creating a vlin driver as well as device specific uart implementations that fix the fifo rx buffer issue, especially for popular devices like the rapsberry pi. I haven't looked into this enough yet but it should be possible to just clone the drivers and modify to force a 1 byte buffer?

ppisa commented 2 years ago

Thanks much to @trainman419 for moving the repo. As for your personal one and redirection, if you do not plan to contribute soon, then if you left automatic redirection, it would work great to guide people to the right place. If you plan to work on the project, then clone repo in previous location and it would be great if you find time to contribute more.

I have copied my wiki text to this new upstream project and updated it to point to it as to the mainline. I have forced my fork wiki in sync, so it points to the right upstream. I have updated links at our university CAN page too https://canbus.pages.fel.cvut.cz/ .

We should include README.md into project as well.

As for the utils, it should be only WIP fork and I hope we can merge soon into master.

As for the drivers, temporal fork or better only patches to force FIFO threshold level to one or disable FIFO should be only temporal solution. We need to find consensus with mainline developers on API to control threshold and or Tx idle timeout.

Thanks for cooperation again, Pavel

hartkopp commented 2 years ago

Hi all, great to see the LIN stuff now gets concentrated here!

As logos are always important, we should replace the 'GitHub-generated' Logo with something LIN specific. There is an excellent full color SVG logo available on Wikipedia: https://de.wikipedia.org/wiki/Local_Interconnect_Network#/media/Datei:Logo_lin_bus.svg

And the https://www.lin-cia.org/ (who took over the administrative jobs from the orphaned lin-subbus.org) has a monochrome logo made of it.

I would suggest to create a monochrome logo from the existing SVG (without the text and maybe using other colors) as the colored version looks like1998 websites ...

I could also thing of a SocketCAN Tux remix - but this organization aims to provide LIN code and ideas not only for Linux.

Any suggestions?

ppisa commented 2 years ago

Hello Oliver, I have added "open" * lin bus quick sketch logo for now as a start... I would be careful about official TM logos... I need to switch to other duties now.... but if you have some proposal, I am open... I would not limit project to Linux only...

*) Partially rotated copyright symbol and orienteering run finish winner air inflated arch.

hartkopp commented 2 years ago

Hello Oliver, I have added "open" * lin bus quick sketch logo for now as a start...

Thanks!

I would be careful about official TM logos...

Yes. The interesting part is, that the trademark was not renewed since 30.08.2019: https://register.dpma.de/DPMAregister/marke/registerHABM?AKZ=001292861

But I've sent a request to https://www.lin-cia.org/ whether the use of the logo would be fine from them too - or whom to ask about it ...

I need to switch to other duties now.... but if you have some proposal, I am open... I would not limit project to Linux only...

Yes. That's fine. We need a proper OSS LIN support for every architecture ;-)