In message: <20090103005040.GA64606_at_onelab2.iet.unipi.it> Luigi Rizzo <rizzo_at_iet.unipi.it> writes: : On Fri, Jan 02, 2009 at 04:33:08PM -0700, M. Warner Losh wrote: : > In message: <20090102210133.GA57653_at_onelab2.iet.unipi.it> : > Luigi Rizzo <rizzo_at_iet.unipi.it> writes: : ... : > : The usage model I expect is that people will be told something like this : > : : > : To support the BenQ T33 phone on FreeBSD/i386 6.x or 7.x do : > : kmodpatch -t "umass.ko umass_devdescrs 4 4 4 2" - - _at_0 0x4050 0x4a5 0x0101 0x4200 : > : : > : to support the Asus M2N-Vm DVI MCP67 ethernet on FreeBSD/i386 7.x do : > : kmodpatch -t "if_nfe.ko nfe_devs 2 2 s" - - _at_0 0x10de 0x54c - : > : and please note TX flow control does not work : > : > This is a good interface for our users? : : i don't know -- in the end it is : "if you trust me, cut&paste this line into a root shell" : which I believe is simpler than : "if you trust me, apply this patch, rebuild the kernel and reinstall" That's debatable :). Let's trade this hard to do thing for this thing that's hard to verify... It might be progress, but it is only tiny, incremental progress... : > It is interesting technology, I'm not sure it is the right tool for : > the device aliasing... : : > It does require some extra care to introduce duplicate entries into : > the table, or reserve space. : : or just overwrite some entry that is unused in your setting, : which again does not work in 100% of the cases but it is very : close to that. Yea, it is a kludge that works... : > With proper aliasing, we could publish : > one big file that has all the new aliases since the last release and : > there'd be no need to modify the leaf drivers. With these : : in principle yes, though that i expect that the source of info is not : freebsd.org (which often does not have a chance to check/try : whether an alias is correct), but rather mailing lists or other users : which happen to have the same device and tried it. I'd suspect it is freebsd.org, with inputs from the mailing lists... WarnerReceived on Sat Jan 03 2009 - 05:11:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:39 UTC