[Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Paweł Chmiel]

śr., 13 lut 2019 o 16:51 Tony Lindgren <tony at atomide.com> napisał(a):
>
> * H. Nikolaus Schaller <hns at goldelico.com> [190213 15:22]:
> > Do you have suggestions for a dedicated mailing list?
>
> How about something like open-pvrsgx-devel at vger.kernel.org?
> I think all you have to do is email the vger.kernel.org
> postmaster and explain what this list is about.
>
> > Or a common git repo to use?
>
> How about initially set up somethign at gitlab/github as
> suggested by Paweł?
>
> And then also get a kernel.org account and start setting
> up a proper open-pvrsgx-devel git branch at git.kernel.org
> eventually for the mainline kernel module(s)?
>
> > As said, I'd prefer kernel.org/staging and linux-omap (because we seem to be the largest group)
> > because it would make things simpler.
>
> Sure, I'm just saying we should wait a bit until we have
> code ready for staging to avoid churning the Linux kernel
> pointlessly initially.
>
> > And there is another aspect which came to my mind just now.
> >
> > Having a separate ML + GIT needs activities to draw attention of other developers while
> > sitting on kernel.org would automatically make use of the existing Linux announcement
> > channels. Some 5.x-rc1 would simply include it. ELIXIR will cross-reference it. Patchwork
> > will archive discussions. LKML will present patches to all potential developers. So we
> > would make use of the existing communication machinery besides a ML.
>
> Yeah there's nothing stopping you from getting a kernel.org
> account and setting up something like open-pvrsgx-devel
> git tree there to start with. As we've discussed, these
> are already GPL components for the kernel although unusable
> in their current form.
>
> > Having it separated needs also some HOWTO for integration and getting it compiled.
> >
> > So I see a lot of benefits.
> >
> > But this would need to get Greg into the boat or at least accept what we are doing and
> > providing resources. You likely know him better than me. How should we contact him?
>
> I think we should just wait on the staging part a bit
> until we have something usable. There will most likely
> be a lot of churn initially.
I also agree to this. In my opinion, we should at first try to get
something working (it doesn't matter where it will be, we can easly
move code it later - just make sure all have access).
Also someone mentioned about adding some prefix to all commits - we
can do this later when we'll be preparing patches for submision (for
example formatting them according to kernel rules, squashing so we
could send them for example with few commits - don't need to send
whole history of changes from repo).
For now we would just need to signoff patches.

>
> Regards,
>
> Tony
>