Peer to Patent, Community Patent Review

APPLICATION LIST|ARCHIVED APPLICATIONS|US PATENT CLASSIFICATIONS

Home > Discussion

Pre-Grant Publication Number: 20070162625

Method and apparatus for delivering device drivers

Filing Date: January 11, 2006

Inventors: Ashley Saulsbury, David Redman, ...

Assignee: SUN MICROSYSTEMS, INC.

Current U.S. Classification: 710, 710/008000

Discussion (6)

View: Date|Claims|Prior Art|Action Item|

Facilitator's Comment

Action Item

Show without Noise

Teddi Maranzano (about 1 year ago)

If a system administrator has installed a 3rd party adapter on his hardware, he gets the vendor's driver as part of the product. The driver is part of the overall install process. Whether he installs the driver into the OS directly or into the service processor ( would that be a firmware layer?), he still is aware of the need to do it. So I don't know he saved himself any work. Also, a lot of customers have security requirements for hardened OS images or other strict controls that would preclude just having the OS go and download a driver. I suppose a central software repository server could be set up to push out required drivers on demand. But don't the major UNIX OS's already have that capability?

Alex Young (about 1 year ago)

It doesn't matter. The point of this invention (as I read it - I stand to be corrected) is to allow you to run an old OS on top of a hypervisor on special hardware, so that the hypervisor asks a coprocessor for the right driver for that OS / hardware combination. The hypervisor basically acts as a multiplexer for the device drivers, and lets you transparently run more than one old OS side-by-side with the service processor (claimed as a solid-state storage area of at least 32MB in Claim 6, so I'm sure they've got flash in mind) providing the correct device driver on boot of that guest OS. The best place I can think of for prior art as far as driver loading is concerned would be the Xen source code, but I'm pretty sure there's no capability there for storing drivers to flash. I'll take a look, anyway, something might show up.

Alex Young (about 1 year ago)

Also worth checking out is the OpenFirmware spec - it's got a lot of similarities to what's being claimed here. There are enough differences between the spec itself and this application that I don't think OF would be prior art, but the similarities are great enough that there may be relevant journal articles that connect the dots. More food for thought...

Teddi Maranzano (about 1 year ago)

I read it that they are talking about vmware containers that can be moved from one h/w platform to another, so that's running an old OS on a newer platform. They're also talking about needing a new driver for a newly installed bit of h/w, and also about updating an existing driver to a newer version. It has to be Non-volatile RAM or other solid state so that the drivers are available prior to OS initialization. This may be beyond the scope of the application, but how would you update the service processor? Through firmware updates to the h/w platform?

Alex Young (about 1 year ago)

That's out of scope, because they aren't claiming anything related to updating the service processor. That being said, I'd handle it with a privileged management OS that downloaded updates over the network and handed them off to the hypervisor for storage via a virtual device driver.

"It has to be Non-volatile RAM or other solid state so that the drivers are available prior to OS initialization."

Not sure I agree with this. All that's necessary is that the hypervisor has access to the drivers during the guest OS boot sequence. If the drivers were stored on disk, that could be arranged via a disk device driver in the hypervisor itself. That would complicate the hypervisor code, though, so it may be that they've gone with firmware storage for simplicity.

Alex Young (about 1 year ago)

That raises another point. If a hypervisor with that design existed, would it invalidate this application? It would invalidate claims 1-5, 7, 8-11 (I think - it depends if the "service processor" in claim 9 can be interpreted as being software in the hypervisor itself) and 13 at least, and put the remaining claims under a non-obviousness test. In that case, I'd argue that moving storage from hard disk to flash was obvious, so claim 6 would fall as well, and the patent would have to stand on claim 14 and its dependents.

0 days left