On In-Kernel Drivers
It’s pretty well-known that the Linux kernel developers advocate getting your drivers into the main line kernel tree. Doing so ensures that your driver always gets fixed to conform to the latest “correct” internal interfaces when they change, and in-kernel device drivers always get distributed with the kernel, so you get automatic end-user distribution for free.
While I agree with that (without touching the question of whether or not a stable driver binary API/ABI would be useful), I’m not entirely sure it’s the best thing in the world for some types of device drivers.
While reading a post by Carl Worth on recent (perceived?) driver stability issues with the Intel video driver for Linux, I came across this bit of insight:
It used to be that getting the latest Intel driver just meant updating an xf86-video-intel module or upgrading an xserver-xorg-video-intel package. But now it’s essential to get a recent kernel as well… And these fixes aren’t in a major kernel release until 2.6.30 which appeared only today.
This is a problem that perhaps highlights some types of drivers that may be served better by being maintained outside the main line Linux kernel tree. Of course, this is only true while the driver is actively maintained and maintainers are able to quickly update the driver for new kernels (without breaking backward compatibility) as in-kernel interfaces change.
He also notes that distribution maintainers tend to update critical parts of the system (like the kernel) less often than userspace portions (like X.org video drivers). Since the xorg-video-intel driver depends on an in-kernel driver, it’s easy for these two things to become out of sync on an end-user’s system without testing. Or, frustratingly, the maintainer of the userspace package for a video driver might be unable to update to a newer version of the userspace driver because the kernel packager doesn’t wish to upgrade the entire kernel to become compatible with that userspace package (which is an entirely reasonable position to take).
And with more video drivers expected to move toward having significant kernel portions, this problem can only get worse. What if the latest userspace package for drivers A and B both depend on kernel 2.6.30, and the maintainer of package A wants to update, but the package B maintainer doesn’t (perhaps there’s a bad bug in the latest version of B)? Even if the A package maintainer can convince the kernel maintainer to update, doing so might break things for other users.
Now, sure, having dependency issues like that is nothing new, but I submit that this is a bit different. The kernel contains so much “unrelated” functionality that it has the potential to be a root dependency of many unrelated packages. For example, if a video player depends on a particular version of a codec library, you can often update that codec library without causing issues with other video players (ignoring, for a moment, ffmpeg’s inability to maintain a stable API). But updating the kernel because a userspace video driver requires a new kernel version could potentially cause problems with anything ranging from a USB storage device, to a hard disk controller, to an audio card.
Now, of course, the Intel video driver has been undergoing some very large changes lately. In theory, these things will settle down, interfaces will stabilize, and you can expect the tight coupling between the kernel version and userspace package version to relax a bit. But perhaps during this transition period it might make sense to avoid merging kernel code like this at all, and instead do separate releases of (in this case) the DRM modules that are paired to the userspace package. I imagine it wouldn’t be too much of a burden for distro packagers to disable building the in-kernel versions of these drivers, and instead ship an extra module package that the userspace driver packages can depend on.
On In-Kernel Drivers
It's pretty well-known that the Linux kernel developers advocate getting your drivers into the main line kernel tree. Doing so ensures that your driver always gets fixed to conform to the latest "correct" internal interfaces when they change, and in-kernel device drivers always get distributed with the kernel, so you get automatic end-user distribution for free.
While I agree with that (without touching the question of whether or not a stable driver binary API/ABI would be useful), I'm not entirely sure it's the best thing in the world for some types of device drivers.
While reading a post by Carl Worth on recent (perceived?) driver stability issues with the Intel video driver for Linux, I came across this bit of insight:
It used to be that getting the latest Intel driver just meant updating an xf86-video-intel module or upgrading an xserver-xorg-video-intel package. But now it's essential to get a recent kernel as well... And these fixes aren't in a major kernel release until 2.6.30 which appeared only today.
This is a problem that perhaps highlights some types of drivers that may be served better by being maintained outside the main line Linux kernel tree. Of course, this is only true while the driver is actively maintained and maintainers are able to quickly update the driver for new kernels (without breaking backward compatibility) as in-kernel interfaces change.
He also notes that distribution maintainers tend to update critical parts of the system (like the kernel) less often than userspace portions (like X.org video drivers). Since the xorg-video-intel driver depends on an in-kernel driver, it's easy for these two things to become out of sync on an end-user's system without testing. Or, frustratingly, the maintainer of the userspace package for a video driver might be unable to update to a newer version of the userspace driver because the kernel packager doesn't wish to upgrade the entire kernel to become compatible with that userspace package (which is an entirely reasonable position to take).
And with more video drivers expected to move toward having significant kernel portions, this problem can only get worse. What if the latest userspace package for drivers A and B both depend on kernel 2.6.30, and the maintainer of package A wants to update, but the package B maintainer doesn't (perhaps there's a bad bug in the latest version of B)? Even if the A package maintainer can convince the kernel maintainer to update, doing so might break things for other users.
Now, sure, having dependency issues like that is nothing new, but I submit that this is a bit different. The kernel contains so much "unrelated" functionality that it has the potential to be a root dependency of many unrelated packages. For example, if a video player depends on a particular version of a codec library, you can often update that codec library without causing issues with other video players (ignoring, for a moment, ffmpeg's inability to maintain a stable API). But updating the kernel because a userspace video driver requires a new kernel version could potentially cause problems with anything ranging from a USB storage device, to a hard disk controller, to an audio card.
Now, of course, the Intel video driver has been undergoing some very large changes lately. In theory, these things will settle down, interfaces will stabilize, and you can expect the tight coupling between the kernel version and userspace package version to relax a bit. But perhaps during this transition period it might make sense to avoid merging kernel code like this at all, and instead do separate releases of (in this case) the DRM modules that are paired to the userspace package. I imagine it wouldn't be too much of a burden for distro packagers to disable building the in-kernel versions of these drivers, and instead ship an extra module package that the userspace driver packages can depend on.
On In-Kernel Drivers
It’s pretty well-known that the Linux kernel developers advocate getting your drivers into the main line kernel tree. Doing so ensures that your driver always gets fixed to conform to the latest “correct” internal interfaces when they change, and in-kernel device drivers always get distributed with the kernel, so you get automatic end-user distribution for [...]Git Weirdness, Part 2
Ok, now this is just ridiculous:
[brian@machine1 airconfig $] pwd /home/brian/src/airconfig [brian@machine1 airconfig $] git branch -a advanced-ip-settings * master nm-frontend notification-rework reconnect origin/master origin/pre-hal [brian@machine1 airconfig $] cd .. && mkdir t && cd t [brian@machine1 t $] git clone ../airconfig Initialized empty Git repository in /home/brian/src/t/airconfig/.git/ [brian@machine1 t $] cd airconfig [brian@machine1 airconfig $] git branch -a * master origin/HEAD origin/advanced-ip-settings origin/master origin/nm-frontend origin/notification-rework origin/reconnect
Ok, that makes sense! Now:
[brian@machine1 airconfig $] cd .. [brian@machine1 t $] rm -rf airconfig [brian@machine1 t $] git clone file:///home/brian/src/airconfig Initialized empty Git repository in /home/brian/src/t/airconfig/.git/ remote: Counting objects: 1272, done. remote: Compressing objects: 100% (486/486), done. remote: Total 1272 (delta 778), reused 1270 (delta 776) Receiving objects: 100% (1272/1272), 360.40 KiB, done. Resolving deltas: 100% (778/778), done. [brian@machine1 t $] cd airconfig [brian@machine1 airconfig $] git branch -a * master origin/HEAD origin/advanced-ip-settings origin/master origin/pre-hal
What. The. Fuck.
Yes, the git-clone man page tells me that, when using a local pathname (and not using a file: URI), it assumes the other repo is local and uses hardlinks between the repos. But hey, if I specify –no-hardlinks when cloning, I still get all branches if I use the “../airconfig” method.
And if I go to machine2 and do “git clone machine1:src/airconfig” I get the same broken result with the file:// method.
Git, I think you rock. But why does your user interface suck so much? And why do you just appear to be broken right now? I can’t seem to find anything else in the man page to help here. (I’m using git 1.6.1.3 if that matters.)
Git Weirdness, Part 2
Ok, now this is just ridiculous:
[brian@machine1 airconfig $] pwd /home/brian/src/airconfig [brian@machine1 airconfig $] git branch -a advanced-ip-settings * master nm-frontend notification-rework reconnect origin/master origin/pre-hal [brian@machine1 airconfig $] cd .. && mkdir t && cd t [brian@machine1 t $] git clone ../airconfig Initialized empty Git repository in /home/brian/src/t/airconfig/.git/ [brian@machine1 t $] cd airconfig [brian@machine1 airconfig $] git branch -a * master origin/HEAD origin/advanced-ip-settings origin/master origin/nm-frontend origin/notification-rework origin/reconnect
Ok, that makes sense! Now:
[brian@machine1 airconfig $] cd .. [brian@machine1 t $] rm -rf airconfig [brian@machine1 t $] git clone file:///home/brian/src/airconfig Initialized empty Git repository in /home/brian/src/t/airconfig/.git/ remote: Counting objects: 1272, done. remote: Compressing objects: 100% (486/486), done. remote: Total 1272 (delta 778), reused 1270 (delta 776) Receiving objects: 100% (1272/1272), 360.40 KiB, done. Resolving deltas: 100% (778/778), done. [brian@machine1 t $] cd airconfig [brian@machine1 airconfig $] git branch -a * master origin/HEAD origin/advanced-ip-settings origin/master origin/pre-hal
What. The. Fuck.
Yes, the git-clone man page tells me that, when using a local pathname (and not using a file: URI), it assumes the other repo is local and uses hardlinks between the repos. But hey, if I specify –no-hardlinks when cloning, I still get all branches if I use the “../airconfig” method.
And if I go to machine2 and do “git clone machine1:src/airconfig” I get the same broken result with the file:// method.
Git, I think you rock. But why does your user interface suck so much? And why do you just appear to be broken right now? I can’t seem to find anything else in the man page to help here. (I’m using git 1.6.1.3 if that matters.)
Git Weirdness, Part 2
Ok, now this is just ridiculous:
[brian@machine1 airconfig $] pwd /home/brian/src/airconfig [brian@machine1 airconfig $] git branch -a advanced-ip-settings * master nm-frontend notification-rework reconnect origin/master origin/pre-hal [brian@machine1 airconfig $] cd .. && mkdir t && cd t [brian@machine1 t $] git clone ../airconfig Initialized empty Git repository in /home/brian/src/t/airconfig/.git/ [brian@machine1 t $] cd airconfig [brian@machine1 airconfig $] git branch -a * master origin/HEAD origin/advanced-ip-settings origin/master origin/nm-frontend origin/notification-rework origin/reconnect
Ok, that makes sense! Now:
[brian@machine1 airconfig $] cd .. [brian@machine1 t $] rm -rf airconfig [brian@machine1 t $] git clone file:///home/brian/src/airconfig Initialized empty Git repository in /home/brian/src/t/airconfig/.git/ remote: Counting objects: 1272, done. remote: Compressing objects: 100% (486/486), done. remote: Total 1272 (delta 778), reused 1270 (delta 776) Receiving objects: 100% (1272/1272), 360.40 KiB, done. Resolving deltas: 100% (778/778), done. [brian@machine1 t $] cd airconfig [brian@machine1 airconfig $] git branch -a * master origin/HEAD origin/advanced-ip-settings origin/master origin/pre-hal
What. The. Fuck.
Yes, the git-clone man page tells me that, when using a local pathname (and not using a file: URI), it assumes the other repo is local and uses hardlinks between the repos. But hey, if I specify --no-hardlinks when cloning, I still get all branches if I use the "../airconfig" method.
And if I go to machine2 and do "git clone machine1:src/airconfig" I get the same broken result with the file:// method.
Git, I think you rock. But why does your user interface suck so much? And why do you just appear to be broken right now? I can't seem to find anything else in the man page to help here. (I'm using git 1.6.1.3 if that matters.)
Git Weirdness
So I have a git repo on my machine at home, that’s cloned from a repo on git.xfce.org. I was doing some work in it the other day — in a private branch, not published to git.xfce.org — and I wanted to continue working on the private branch from another machine. But… it won’t work. Let’s say ‘machine1′ has the repo with the private branch, and ‘machine2′ is where I want to work today.
So, on machine2, I cloned from the master repo on git.xfce.org:
[brian@machine2 src $] git clone git@git.xfce.org:kelnos/airconfig [... stuff happens...] [brian@machine2 src $] cd airconfig [brian@machine2 airconfig $] git branch -a * master origin/master origin/pre-hal
Ok, cool, that’s what I expect. So I ssh over to machine1 (the one I eventually want to pull from), and I check out my list of branches there:
[brian@machine1 airconfig $] git branch -a advanced-ip-settings master * nm-frontend notification-rework reconnect origin/master origin/pre-hal
Ok, cool. the ‘nm-frontend’ branch is the one I want to pull to machine2. So on machine2, I do this:
[brian@machine2 airconfig $] git remote add machine1 machine1:src/airconfig [brian@machine2 airconfig $] git pull machine1 nm-frontend fatal: Couldn't find remote ref nm-frontend fatal: The remote end hung up unexpectedly
Uh… what? Do I have the wrong syntax? Ok, let me just try to pull everything from the remote:
[brian@machine2 airconfig $] git pull machine1 remote: Counting objects: 1085, done. remote: Compressing objects: 100% (301/301), done. remote: Total 1085 (delta 774), reused 1085 (delta 774) Receiving objects: 100% (1085/1085), 323.43 KiB | 14 KiB/s, done. Resolving deltas: 100% (774/774), done. From machine1:src/airconfig * [new branch] advanced-ip-settings -> machine1/advanced-ip-settings * [new branch] master -> machine1/master * [new branch] pre-hal -> machine1/pre-hal
And then at the bottom it prints out a message about not knowing which local branches to merge stuff into. That’s fine, no big deal. But… how come it pulled 3 of my local branches on machine1, but left off 2 of them (‘notification-rework’ and ‘nm-frontend’). No combination of src:dest refspecs seem to do the trick. Pulling one of the 3 branches it seems to like using the syntax I used above seems to work fine, but it can’t see the one I want. What am I doing wrong…?
Git Weirdness
So I have a git repo on my machine at home, that's cloned from a repo on git.xfce.org. I was doing some work in it the other day -- in a private branch, not published to git.xfce.org -- and I wanted to continue working on the private branch from another machine. But... it won't work. Let's say 'machine1' has the repo with the private branch, and 'machine2' is where I want to work today.
So, on machine2, I cloned from the master repo on git.xfce.org:
[brian@machine2 src $] git clone git@git.xfce.org:kelnos/airconfig [... stuff happens...] [brian@machine2 src $] cd airconfig [brian@machine2 airconfig $] git branch -a * master origin/master origin/pre-hal
Ok, cool, that's what I expect. So I ssh over to machine1 (the one I eventually want to pull from), and I check out my list of branches there:
[brian@machine1 airconfig $] git branch -a advanced-ip-settings master * nm-frontend notification-rework reconnect origin/master origin/pre-hal
Ok, cool. the 'nm-frontend' branch is the one I want to pull to machine2. So on machine2, I do this:
[brian@machine2 airconfig $] git remote add machine1 machine1:src/airconfig [brian@machine2 airconfig $] git pull machine1 nm-frontend fatal: Couldn't find remote ref nm-frontend fatal: The remote end hung up unexpectedly
Uh... what? Do I have the wrong syntax? Ok, let me just try to pull everything from the remote:
[brian@machine2 airconfig $] git pull machine1 remote: Counting objects: 1085, done. remote: Compressing objects: 100% (301/301), done. remote: Total 1085 (delta 774), reused 1085 (delta 774) Receiving objects: 100% (1085/1085), 323.43 KiB | 14 KiB/s, done. Resolving deltas: 100% (774/774), done. From machine1:src/airconfig * [new branch] advanced-ip-settings -> machine1/advanced-ip-settings * [new branch] master -> machine1/master * [new branch] pre-hal -> machine1/pre-hal
And then at the bottom it prints out a message about not knowing which local branches to merge stuff into. That's fine, no big deal. But... how come it pulled 3 of my local branches on machine1, but left off 2 of them ('notification-rework' and 'nm-frontend'). No combination of src:dest refspecs seem to do the trick. Pulling one of the 3 branches it seems to like using the syntax I used above seems to work fine, but it can't see the one I want. What am I doing wrong...?
Git Weirdness
So I have a git repo on my machine at home, that’s cloned from a repo on git.xfce.org. I was doing some work in it the other day – in a private branch, not published to git.xfce.org – and I wanted to continue working on the private branch from another machine. But… it won’t work. Let’s say ‘machine1’ has the repo with the private branch, and ‘machine2’ is where I want to work today.
So, on machine2, I cloned from the master repo on git.xfce.org:
[brian@machine2 src $] git clone git@git.xfce.org:kelnos/airconfig [... stuff happens...] [brian@machine2 src $] cd airconfig [brian@machine2 airconfig $] git branch -a * master origin/master origin/pre-hal
Ok, cool, that’s what I expect. So I ssh over to machine1 (the one I eventually want to pull from), and I check out my list of branches there:
[brian@machine1 airconfig $] git branch -a advanced-ip-settings master * nm-frontend notification-rework reconnect origin/master origin/pre-hal
Ok, cool. the ‘nm-frontend’ branch is the one I want to pull to machine2. So on machine2, I do this:
[brian@machine2 airconfig $] git remote add machine1 machine1:src/airconfig [brian@machine2 airconfig $] git pull machine1 nm-frontend fatal: Couldn't find remote ref nm-frontend fatal: The remote end hung up unexpectedly
Uh… what? Do I have the wrong syntax? Ok, let me just try to pull everything from the remote:
[brian@machine2 airconfig $] git pull machine1 remote: Counting objects: 1085, done. remote: Compressing objects: 100% (301/301), done. remote: Total 1085 (delta 774), reused 1085 (delta 774) Receiving objects: 100% (1085/1085), 323.43 KiB | 14 KiB/s, done. Resolving deltas: 100% (774/774), done. From machine1:src/airconfig * [new branch] advanced-ip-settings -> machine1/advanced-ip-settings * [new branch] master -> machine1/master * [new branch] pre-hal -> machine1/pre-hal
And then at the bottom it prints out a message about not knowing which local branches to merge stuff into. That’s fine, no big deal. But… how come it pulled 3 of my local branches on machine1, but left off 2 of them (‘notification-rework’ and ‘nm-frontend’). No combination of src:dest refspecs seem to do the trick. Pulling one of the 3 branches it seems to like using the syntax I used above seems to work fine, but it can’t see the one I want. What am I doing wrong…?