> > > > > > "drm_minor" is not necessary anymore. Strictly managing minor numbers > > > lost its value years ago when /dev/ was reorganized. Just use > > > dynamic minors fully. > > drm minor is not just about handling minor numbers. It contains the > > entire code to manage devices that register with drm framework (e.g. > > supply callbacks to file operations), manage their lifecycle, > > resources (e.g. automatic free of resources on release), sysfs, > > debugfs, etc. > > This is why you are having such troubles, this is already good library > code. You don't need DRM to wrapper debugfs APIs, for instance. We > have devm, though maybe it is not a good idea, etc > > Greg already pointed out the sysfs was not being done correctly > anyhow. > > I don't think DRM is improving on these core kernel services. Just use > the normal stuff directly. At plumbers we decided a direction, I think the direction is good, if there is refactoring to be done, I'd rather it was done in tree with a clear direction. Coming in now and saying we should go down a different path isn't really helpful. We need to get rolling on this, we have drivers that want to land somewhere now, which means we need to just get a framework in place, leveraging drm code is the way to do it. There is no need to an "accel" module, what does that even buy you, the idea is to have an accel subsystem that allows drivers to use drm features, not an accel subsystem that refactors drm features, that would take years. There are already drivers for this subsystem wanting to use GEM, and I don't think holding them up for a year to refactor something that we don't have a clear reason or goal behind refactoring. If there is a problem with the drm subsystem interactions with the kernel standard implementations then let's go fix that and accel will also get fixed, but there's no reason to start going down that road at the same time as introducing accel. Also with the idr/xarray stuff, this isn't the patchset to be introducing a bunch of new and divergent work, if this patchset identifies deficiencies then let's document them and work on them in parallel instead of blocking the initial landing in favour of some future refactors with no in-tree users. Dave.
