On Tue, Oct 15, 2002 at 02:34:50PM -0700, Steven Dake wrote:
> >Given that there are a number of kernel developers working their
> >respective asses off trying to get devfs out of the kernel (by obsoleting
> >it), I would not really recommend tying your driver to it if you want it
> >to be around for very long :)
> >
> >
> What is replacing devfs? Atleast for kernel 2.4, devfs is a good
> solution. Is something new in 2.5 used to provide device nodes at
> kernel runtime?
A combination of /sbin/hotplug notification, and information in the
driverfs tree will enable userspace to create and remove device nodes
whereever and with whatever name they want to.
> We didn't drop picmg2.12 support at all. What was dropped was the
> initial prototype implementation that used those minors (and has been
> replaced by a better implementation that doesn't use them). PICMG 2.12
> support (as well as redundant system slot) is still supported in the CGL
> tress and in MontaVista Linux. I don't know much about picmg 2.12
> implementation, another developer @ Mvista is doing the work.
My main complaint (as the pci hotplug maintainer) is that Mvista isn't
trying to work with the community for their code. I had a number of
good emails with the main developer (at the time), but unfortunatly I
haven't heard anything in quite some time. Any proding you might
provide in this area would be greatly appreciated.
Otherwise Mvista is going to be supporting that patch outside of the
main tree for forever, and that can get old and expensive over time.
> >As I mentioned previously, this can probably be done in userspace (unless
> >you have some unreasonable performance reasons, what are the
> >requirements?)
> >
> >
> 20 msec from hotswap request to disk extraction.
Yes, that sounds pretty unreasonable :) What drives such a quick
request turnaround time?
> The functionality is intertwined in devfs_register_partition. I don't
> think I understand what you mean here, could you expand in mail?
Hm, ok, let me go dig up the patch again, ugh. Ok, I don't really know
how, but it could proably be done cleaner :)
> Ok and I'll take a look at using ramfs and driverfs instead of devfs and
> ioctls in both patches for the 2.5 tree. We may probably keep the patch
> for the 2.4 tree since I dont think there is driverfs or ramfs in 2.4.
Yes, ramfs is in 2.4, and the pci hotplug core uses a filesystem just
like this in the 2.4 kernel. But if you want to keep your patch out of
the kernel, it's fine with me :)
> >That's up to the QLogic people, I'm just too confused with the vast
> >number of different drivers from them :)
> >
> >
> Mark Bellon @ MontaVista is working with them to support their driver in
> MontaVista Linux. We have made a number of quality improvements and
> submitted them back to Qlogic. We have talked to their development team
> and they would be willing to submit their Qlogic 6 driver to the Linux
> kernel. We can do the integration work here of including it in the
> kernel. Should I submit a patch to the list ?
Here, and/or to the linux-scsi mailing list.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:57 EST