On Thu, Feb 09, 2006 at 10:39:55AM +0100, Joerg Schilling wrote: > "Jim Crilly" <[email protected]> wrote: > > > > You just verify that you don't listen... > > > > Yes, I have been listening and I haven't seen you list one reason why > > cdrecord absolutely has to use SCSI IDs when fsck can get away with using > > /dev/blah just fine. > > Are you _really_ missing basic know how to understand that fsck is using the > block layer of a virtual "block device" emulated by UNIX while libscg is > offering _direct_ acces to _any_ type of device allowing you to send _commands_ > understood by the device? > > fsck is just sending abstract instructions to a virtual device and does > not care about > > Please explain me: > > - how to use /dev/hd* in order to scan an image from a scanner > > - how to use /dev/hd* in order to talk to a CPU device > > - how to use /dev/hd* in order to talk to a tape device > > - how to use /dev/hd* in order to talk to a printer > > - how to use /dev/hd* in order to talk to a jukebox > > - how to use /dev/hd* in order to talk to a graphical device Hi I have been following this thread for quite a while, would just like to point out that you are quick pedantic about accuracy. so even though it might be a bit of a pain to create a file called /dev/hd*, I believe with mknod you could assign this name to any device you wanted to or even symlink it to any device so you could use you /dev/hd* the same way as you used /dev/sda etc > > J?rg > > -- > EMail:[email protected] (home) J?rg Schilling D-13353 Berlin > [email protected] (uni) > [email protected] (work) Blog: http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
Attachment:
signature.asc
Description: Digital signature
- References:
- Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- From: Peter Read <[email protected]>
- Re: CD writing in future Linux (stirring up a hornets' nest)
- From: Matthias Andree <[email protected]>
- Re: CD writing in future Linux (stirring up a hornets' nest)
- From: "Jim Crilly" <[email protected]>
- Re: CD writing in future Linux (stirring up a hornets' nest)
- From: Joerg Schilling <[email protected]>
- Re: CD writing in future Linux (stirring up a hornets' nest)
- From: "Jim Crilly" <[email protected]>
- Re: CD writing in future Linux (stirring up a hornets' nest)
- From: Joerg Schilling <[email protected]>
- Re: CD writing in future Linux (stirring up a hornets' nest)
- From: "Jim Crilly" <[email protected]>
- Re: CD writing in future Linux (stirring up a hornets' nest)
- From: Joerg Schilling <[email protected]>
- Re: CD writing in future Linux (stirring up a hornets' nest)
- From: "Jim Crilly" <[email protected]>
- Re: CD writing in future Linux (stirring up a hornets' nest)
- From: Joerg Schilling <[email protected]>
- Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- Prev by Date: Re: [stable] Re: [patch 6/6] [NETFILTER]: Fix another crash in ip_nat_pptp (CVE-2006-0037)
- Next by Date: Re: msync() behaviour broken for MS_ASYNC, revert patch?
- Previous by thread: Re: CD writing in future Linux (stirring up a hornets' nest)
- Next by thread: Re: CD writing in future Linux (stirring up a hornets' nest)
- Index(es):
 |