-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setup mainline/ustream repo which is easy to find #4
Comments
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. |
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! |
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? |
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 |
Hi all, As logos are always important, we should replace the 'GitHub-generated' Logo with something LIN specific. 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? |
Hello Oliver, I have added "open" * lin bus quick sketch logo for now as a start... *) Partially rotated copyright symbol and orienteering run finish winner air inflated arch. |
Thanks!
Yes. The interesting part is, that the trademark was not renewed since 30.08.2019: 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 ...
Yes. That's fine. We need a proper OSS LIN support for every architecture ;-) |
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
The text was updated successfully, but these errors were encountered: