i remember reading before that libusb really makes more sense as an architecture standpoint for usb drivers. its like the bluetooth stack. you just make a kernel driver for the usb host and connections, but as far as the specific bits for controlling the usb device. thats how bluetooth is done right now. apparently wifi driver would be better to be done that way too. even graphics drivers are kinda similar except proboboly a level higher up. kernel drm talks to the low level end of the graphics card, but the gallium/mesa stack does the translation work.
it would be nice if a lot more of the linux kernel moved to userspace as long as its reasonable. for instance fuse, i like the idea of fuse, i know old kernel hackers hate it and say its too slow, but it doesn't really have to be. it makes sense, the hard drive driver is all hardware, and it belongs in the kernel, but the file system is all how you prep the data to be sent to the drive, thats like gallium/mesa, and probobly should be done in userspace. the major advantage of userspace is how easy it is to upgrade it and much harder to crash the system. the downside is your further away from the kernel and less ability to verify or check the driver. microsoft went with basicaly a fully userspace driver model up through xp, and that is a testiment to how bad userspace driver CAN be, if you let it. also, a large part of linux's fully open source driver portfolio is directly attributed to how almost everything is kernel based drivers. by making it harder to make userspace drivers, you keep everyhting in the kernel, and things that are in the kernel are gpl and controlled by the kernel devs. if we had a windows xp like driver architecture, you would be getting your driver just like how you do with windows, get it straight from the vendors and they would all be closed source.
also, a large part of linux's fully open source driver portfolio is directly attributed to how almost everything is kernel based drivers. by making it harder to make userspace drivers, you keep everyhting in the kernel, and things that are in the kernel are gpl and controlled by the kernel devs. if we had a windows xp like driver architecture, you would be getting your driver just like how you do with windows, get it straight from the vendors and they would all be closed source.
Linux actually allows closed source drivers, as binary blobs, or obfuscated code. This is a real issue now, not a possibility. So, no, nothing would change.
a lot of vendors get around the gpl by making an ope source shim and make most of the driver a blob, this is how nvidia does it, when you run their little installer it compiles thier gpl kernel code and it has to do that to make thier blob glue to the kernel. intel has before released the wifi driver code bet kept the firmware for the wifi chips closed, many other wifi vendors do the same. thats not so bad since often hardware firmware is just stored on the hardware anyway, it doesnt really have all that much to do with the OS, your are just throwing it into the hardware and tirning it on, but it is really anoying to have to do and thier requirments and restrictions on redistributing the firmware s what causes most of the headaches.
now, i know thats not what you are talking about, you are talking about the export gpl flag how companies are writing closed source kernel modules since they are not touching code that has that flag on it. it has been done before for wifi drivers, but it wasnt very long before vendors learned it wasnt feasible for desktop liux because as soon as a new kernel came out people were blasting their support lines and forums about how to get the driver working again.
where you really see this as a problem is embeded linux, particularly android phones and network routers. pretty much the whole reasin android phones cant be updated like general linux can is because of blob drivers. since network routers often use special wifi chips since they are at the center of traffic, manufacturers often only release a driver for a specific kernel version. as far as phones go, i cant imagin that will last much longer because people really get pissed when the phone they bought a year ago can't use application x because they have android version x and they need version x+1. as android gaines more and more genral linux componants and the hardware it runs on gets more and mre capable, people will expect them to stay up to date like thier latops do.