\
- Host, to which that console connects (through the debug device); runs usb_debug, much like any other usb-serial device
My understanding was that the client could run in user space only on top of libusb.
It's analagous to debugging an embedded box using a serial console with a Linux host ... except the target here is a PC, not an ARM (or PPC, MIPS, etc) custom board.
Once the coexistence issues between the debug port and normal EHCI driver get worked, there's no reason not to keep using that debug port as a system console.
One reason is the one I covered in my last mail -- locking of the PCI type 1 ports.
However I suppose it would be ok to switch Eric's code between early pci access and locked one once the PCI subsystem is up and running. Just don't forget bust_spinlocks()
-Andi
Andi Kleen ak@suse.de writes:
\
- Host, to which that console connects (through the debug device); runs usb_debug, much like any other usb-serial device
My understanding was that the client could run in user space only on top of libusb.
Looks like a normal serial port with greg's patch. I still need to try it though.
One reason is the one I covered in my last mail -- locking of the PCI type 1 ports.
However I suppose it would be ok to switch Eric's code between early pci access and locked one once the PCI subsystem is up and running. Just don't forget bust_spinlocks()
No pci access on that path.
Eric
However I suppose it would be ok to switch Eric's code between early pci access and locked one once the PCI subsystem is up and running. Just don't forget bust_spinlocks()
No pci access on that path.
Hmm good point. Ok ignore that then.
keep should be default then.
-Andi
On Wednesday 06 December 2006 1:24 pm, Andi Kleen wrote:
- Host, to which that console connects (through the debug device); runs usb_debug, much like any other usb-serial device
My understanding was that the client could run in user space only on top of libusb.
I suppose it could, if you didn't want to use it like a normal serial consoe.
It's analagous to debugging an embedded box using a serial console with a Linux host ... except the target here is a PC, not an ARM (or PPC, MIPS, etc) custom board.
Once the coexistence issues between the debug port and normal EHCI driver get worked, there's no reason not to keep using that debug port as a system console.
One reason is the one I covered in my last mail -- locking of the PCI type 1 ports.
That'd be part of coexistence. The debug port is _designed_ to share two different drivers like that ... EHCI can see, as it comes up, whether the debug port is in use, and could then ignore it. (At least, unless/until the debug device gets removed.)
- Dave
-
Andi Kleen -
David Brownell -
ebiederm＠xmission.com