> > What I have works. Your consumers get quirk handling, mine don't need it. > > No compromise. > > Hi Don > > All this discussion is now a mute point. GregKH has spoken.
Ack. I actually checked in with Greg a couple of days ago and got that answer. I just thought the discussion was going in an interesting direction and didn't want to end it yet. Response below is in the same vein. > > But i'm sure there are some on the side lines, eating popcorn, maybe > learning from the discussion. Honestly not sure what they are learning from the discussion. I think what I learned is not what you think you taught me. > > Would you think it is O.K. to add a KAPI which works for 3 1/2" SCSI disks, but > not 2", because you only make machines with 3 1/2" bays? No. Not sure how the analogy works. QSFP is a larger form factor than SFP, and the EEPROM layout changed at the same time, but optoe and my community had no problem accommodating both. CMIS changed the EEPROM layout again, but it was easily accommodated. > > This is an extreme, absurd example, but hopefully you get the point. We > don't design KAPIs with the intention to only work for a subset of devices. It > needs to work with as many devices as possible, even if the first > implementation below the KAPI is limited to just a subset. Let me run with your example... Suppose I used those 3 1/2" SCSI disks to build storage servers. Let's call them RAID devices. Innovation follows, I figure out how to make these devices hot swappable, hot backup, massively parallel... Innovation follows and I evolve this into a distributed architecture with redundant data, encrypted, compressed, distributed across servers and data centers. Massively parallel, synchronized, access to the data anywhere in the world, at bandwidth limited only by the size of your network pipe. Let's call it RIDSS (Redundant, Independent, Distributed Storage Servers). And I can use 2" disks. Or non-spinning storage. My fancy technology thinks the storage is dumb. I present a track/sector/length and I get back the bits. Just for grins, let's say I can also query the device for a list of bad blocks (sectors, whatever). Recently, with the addition of 2" devices, YOU figured out that you can stuff several disks into a small space, and manage them with software and call it RAID. You build a nice abstraction for storage, which contains individual disks, and handles parallelism, redundancy, hot swap. Very cool, works well, a genuine innovation. I've been using Linux for RIDSS for years, I get the memo that my linux driver to access these SCSI devices should be in the upstream kernel. Oddly, there are no drivers in the kernel that I can just present track/sector/length and get back the bits. So, I offer mine. The answer is no, that is a RAID device, you need to access the device through RAID data structures and APIs. Sorry, no, that is not a RAID device. That is a storage device. You use it for RAID storage, I use it for RIDSS storage. We need a layered architecture with raw data access at the bottom (we both need the same track/sector/length access). Beyond that, your RAID stack, while brilliant, has virtually nothing to do with my RIDSS stack. They sound superficially similar, but the technology and architecture are wildly different. The RAID stack is unnecessary for my RIDSS architecture, and requires widespread changes to my software that yield no benefit. So, no, I don't get your point. I think there is value in a simple layered architecture, where access to the module EEPROM is independent of the consumer of that access. You can access it for kernel networking, which is useful, innovative, valuable. I can access it for TOR switches which do not use kernel networking but are nonetheless useful, innovative, valuable. Your decision to reject optoe means the TOR community has to maintain this simple bit of kernel code outside the mainline tree. The judges have ruled, case closed. > > Anyway, i'm gratefull you have looked at the new ethtool netlink KAPI. It will > be better for your contributions. And i hope you can make use of it in the Thanks for the acknowledgement. > future. But i think this discussion about optoe in mainline is over. This discussion is indeed over if you say it is. I'll be moving on :-(. > > Andrew Don
