- 11 1月, 2006 1 次提交
-
-
由 Christoph Hellwig 提交于
Add a compat_ioctl method to the dasd driver so the last entries in arch/s390/kernel/compat_ioctl.c can go away. Unlike the previous attempt this one does not replace the ioctl method with an unlocked_ioctl method so that the ioctl_by_bdev calls in s390 partition code continue to work. Signed-off-by: NChristoph Hellwig <hch@lst.de> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 07 1月, 2006 1 次提交
-
-
由 Horst Hummel 提交于
To properly support multipath-failover handling, the linux block layer has introduced a special request flag, 'REQ_FAILFAST'. This flag is now used to return requests immediately in case the device is not operational. Signed-off-by: NHorst Hummel <horst.hummel@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 05 9月, 2005 1 次提交
-
-
由 Horst Hummel 提交于
Reintroduce a read-only copy of the devmap features in the device struct. This is necessary to solve a deadlock on the dasd_devmap_lock which is acquired by dasd_get_features called from the dasd tasklet. The current implementation of devmap doesn't allow to call any devmap function from interrupt or softirq context. Signed-off-by: NHorst Hummel <horst.hummel@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 01 5月, 2005 1 次提交
-
-
由 Horst Hummel 提交于
The independent read-only flags in devmap, dasd_device and gendisk are not kept in sync. Use one bit per feature in the dasd driver and keep that bit in sync with the gendisk bit. Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-