lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20231107154848.GP4488@nvidia.com> Date: Tue, 7 Nov 2023 11:48:48 -0400 From: Jason Gunthorpe <jgg@...dia.com> To: "Michael S. Tsirkin" <mst@...hat.com> Cc: Cindy Lu <lulu@...hat.com>, jasowang@...hat.com, yi.l.liu@...el.com, linux-kernel@...r.kernel.org, virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org Subject: Re: [RFC v1 0/8] vhost-vdpa: add support for iommufd On Tue, Nov 07, 2023 at 09:55:26AM -0500, Michael S. Tsirkin wrote: > On Tue, Nov 07, 2023 at 08:49:02AM -0400, Jason Gunthorpe wrote: > > IMHO, this patch series needs to spend more time internally to Red Hat > > before it is presented to the community. > > Just to add an example why I think this "internal review" is a bad idea > I seem to recall that someone internal to nvidia at some point > attempted to implement this already. The only output from that > work we have is that "it's tough" - no pointers to what's tough, > no code to study even as a bad path to follow. > And while Red Hat might be big, the virt team is rather smaller. I don't think Nicolin got to a presentable code point. But you can start to see the issues even in this series, like simulator is complicated. mlx5 is complicated. Deciding to omit those is one path. Come with a proposal and justification to take it out, not a patch with an unexplained #ifdef. Again, I'm not talking about big impactful decisions I'm saying RH should take it internally to get a RFC proposal to the level where it is actually an RFC proposal and not a brain dump. Make sure it has logical commit messages, make sure the basic thinking about the idea is done and the proposal is self consistent and explained. Make sure the patches and series construction meet a kernel standard. The purpose of the RFC is to clearly articulate what it is you are asking to do, why you want to do it, and how you intend to get there. There is still alot of basic work to achieve this and properly communicate it. Training to do that should rightly come from the employeer, not the community. We've seen some big blow ups because some companies have been trying to externalize their training to the community. Jason
Powered by blists - more mailing lists