Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #238011 > unrolled thread

Re: what binds to port

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: what binds to port "Thomas Schmitt" <scdbackup@gmx.net> - 2021-08-02 10:00 +0200
    Re: what binds to port mick crane <mick.crane@gmail.com> - 2021-08-02 10:20 +0200
    Re: what binds to port Nicolas George <george@nsup.org> - 2021-08-02 10:40 +0200
      Re: what binds to port Brian <ad44@cityscape.co.uk> - 2021-08-02 16:10 +0200
        Re: what binds to port Nicolas George <george@nsup.org> - 2021-08-02 17:40 +0200
          Re: what binds to port Brian <ad44@cityscape.co.uk> - 2021-08-02 18:00 +0200
            Re: what binds to port Nicolas George <george@nsup.org> - 2021-08-16 20:00 +0200
              Re: what binds to port Brian <ad44@cityscape.co.uk> - 2021-08-16 21:00 +0200
                Re: what binds to port Brian <ad44@cityscape.co.uk> - 2021-08-17 12:30 +0200
    Re: what binds to port Brian <ad44@cityscape.co.uk> - 2021-08-02 12:30 +0200
      Re: what binds to port "Thomas Schmitt" <scdbackup@gmx.net> - 2021-08-02 13:30 +0200
        Re: what binds to port Brian <ad44@cityscape.co.uk> - 2021-08-02 14:10 +0200

#238011 — Re: what binds to port

Hi,

i wrote:
> > /dev/sg2 might be the generic SCSI device to which /dev/sr0 is connected.

mick crane wrote:
> Drive type   : vendor 'PLDS' product 'DVD+-RW DS-8A9SH' revision 'ED11'

So it's clearly the DVD burner which is at sg2.

Do you have any sg device left as suspect for the scanner's device file,
after you subtracted one for each hard disk and each optical drive ?
(I.e. are there two hard disks to occupy sg0 and sg1 and no other sgX left ?)


Have a nice day :)

Thomas

[toc] | [next] | [standalone]

#238012

On 2021-08-02 08:55, Thomas Schmitt wrote:
> Hi,
> 
> i wrote:
>> > /dev/sg2 might be the generic SCSI device to which /dev/sr0 is connected.
> 
> mick crane wrote:
>> Drive type   : vendor 'PLDS' product 'DVD+-RW DS-8A9SH' revision 
>> 'ED11'
> 
> So it's clearly the DVD burner which is at sg2.
> 
> Do you have any sg device left as suspect for the scanner's device 
> file,
> after you subtracted one for each hard disk and each optical drive ?
> (I.e. are there two hard disks to occupy sg0 and sg1 and no other sgX 
> left ?)

doesn't seem to be.
root@pumpkin:/dev# ls -la |grep sg
drwxr-xr-x   2 root root         180 Jul 31 18:20 bsg
crw-r--r--   1 root root      1,  11 Jul 31 17:20 kmsg
crw-rw----   1 root disk     21,   0 Jul 31 17:20 sg0
crw-rw----   1 root disk     21,   1 Jul 31 17:20 sg1
crw-rw----+  1 root cdrom    21,   2 Jul 31 17:20 sg2

lsusb
Bus 002 Device 004: ID 04c5:1095 Fujitsu, Ltd

I don't know anything about usb
Everything is working now. using the scanner button seems maybe a second 
or so slower than XSane to get going but I think I'll leave alone.
cheers
mick
-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#238013

[Multipart message — attachments visible in raw view] — view raw

Thomas Schmitt (12021-08-02):
> Do you have any sg device left as suspect for the scanner's device file,
> after you subtracted one for each hard disk and each optical drive ?
> (I.e. are there two hard disks to occupy sg0 and sg1 and no other sgX left ?)

Have SCSI scanners been spotted since the 20th century, except in zoos?

Only USB mass storage devices are shown as SCSI devices, because they
use mostly the same command set. Other USB devices either have their own
kernel drivers (printers…) or appear as generic USB devices nodes to be
accessed with libusb.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#238036

On Mon 02 Aug 2021 at 10:36:22 +0200, Nicolas George wrote:

> Thomas Schmitt (12021-08-02):
> > Do you have any sg device left as suspect for the scanner's device file,
> > after you subtracted one for each hard disk and each optical drive ?
> > (I.e. are there two hard disks to occupy sg0 and sg1 and no other sgX left ?)
> 
> Have SCSI scanners been spotted since the 20th century, except in zoos?

I have one in captivity here :). 1990s vintage.
 
> Only USB mass storage devices are shown as SCSI devices, because they
> use mostly the same command set. Other USB devices either have their own
> kernel drivers (printers…) or appear as generic USB devices nodes to be
> accessed with libusb.

Helpful remarks, but I did not think printers used kernel drivers.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#238038

[Multipart message — attachments visible in raw view] — view raw

Brian (12021-08-02):
> Helpful remarks, but I did not think printers used kernel drivers.

AFAIR, USB printers appear as a special device, unlike generic USB
devices, that makes one layer of drivers, but then you need an userland
driver, probably GhostScript, to talk the proper language to that
device, and that makes a second layer of drivers.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#238042

On Mon 02 Aug 2021 at 17:35:46 +0200, Nicolas George wrote:

> Brian (12021-08-02):
> > Helpful remarks, but I did not think printers used kernel drivers.
> 
> AFAIR, USB printers appear as a special device, unlike generic USB
> devices, that makes one layer of drivers, but then you need an userland
> driver, probably GhostScript, to talk the proper language to that
> device, and that makes a second layer of drivers.

My thinking is that a USB printer uses libusb, just as a scanner does.
No kernel driver involved. The printer drivers are "internal" to CUPS.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#238834

[Multipart message — attachments visible in raw view] — view raw

Brian (12021-08-02):
> My thinking is that a USB printer uses libusb, just as a scanner does.
> No kernel driver involved. The printer drivers are "internal" to CUPS.

The output of `/sbin/modinfo usblp` confirms there is a kernel driver
for USB printers.

filename:       /lib/modules/5.10.0-8-amd64/kernel/drivers/usb/class/usblp.ko
license:        GPL
description:    USB Printer Device Class driver
author:         Michael Gee, Pavel Machek, Vojtech Pavlik, Randy Dunlap, Pete Zaitcev, David Paschal

It is entirely possible that both this and generic libusb access are
supported.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#238836

On Mon 16 Aug 2021 at 19:51:50 +0200, Nicolas George wrote:

> Brian (12021-08-02):
> > My thinking is that a USB printer uses libusb, just as a scanner does.
> > No kernel driver involved. The printer drivers are "internal" to CUPS.
> 
> The output of `/sbin/modinfo usblp` confirms there is a kernel driver
> for USB printers.
> 
> filename:       /lib/modules/5.10.0-8-amd64/kernel/drivers/usb/class/usblp.ko
> license:        GPL
> description:    USB Printer Device Class driver
> author:         Michael Gee, Pavel Machek, Vojtech Pavlik, Randy Dunlap, Pete Zaitcev, David Paschal

The existence of the usblp kernel module is not in doubt.

> It is entirely possible that both this and generic libusb access are
> supported.

The printing system detaches usblp when it is met.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#238861

On Mon 16 Aug 2021 at 19:55:49 +0100, Brian wrote:

> On Mon 16 Aug 2021 at 19:51:50 +0200, Nicolas George wrote:
> 
> > Brian (12021-08-02):
> > > My thinking is that a USB printer uses libusb, just as a scanner does.
> > > No kernel driver involved. The printer drivers are "internal" to CUPS.
> > 
> > The output of `/sbin/modinfo usblp` confirms there is a kernel driver
> > for USB printers.
> > 
> > filename:       /lib/modules/5.10.0-8-amd64/kernel/drivers/usb/class/usblp.ko
> > license:        GPL
> > description:    USB Printer Device Class driver
> > author:         Michael Gee, Pavel Machek, Vojtech Pavlik, Randy Dunlap, Pete Zaitcev, David Paschal
> 
> The existence of the usblp kernel module is not in doubt.
> 
> > It is entirely possible that both this and generic libusb access are
> > supported.
> 
> The printing system detaches usblp when it is met.

>From /cups/cups-2.3.0/backend/usb-libusb.c:

 /*
  * Get the "usblp" kernel module out of the way. This backend only
  * works without the module attached.
  */

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#238015

On Mon 02 Aug 2021 at 09:55:17 +0200, Thomas Schmitt wrote:

> Hi,
> 
> i wrote:
> > > /dev/sg2 might be the generic SCSI device to which /dev/sr0 is connected.
> 
> mick crane wrote:
> > Drive type   : vendor 'PLDS' product 'DVD+-RW DS-8A9SH' revision 'ED11'
> 
> So it's clearly the DVD burner which is at sg2.
> 
> Do you have any sg device left as suspect for the scanner's device file,
> after you subtracted one for each hard disk and each optical drive ?
> (I.e. are there two hard disks to occupy sg0 and sg1 and no other sgX left ?)

Isn't /dev/sg0 the block device?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#238018

Hi,

Brian wrote:
> Isn't /dev/sg0 the block device?

/dev/sgX are character devices.

  https://tldp.org/HOWTO/SCSI-Generic-HOWTO/intro.html
says
  "The driver's purpose is to allow SCSI commands to be sent directly to
   SCSI devices. [...] Various specialized applications for writing
   CD-Rs and document scanning use the sg driver."

This is still the case for optical drives (sr) and hard discs (sd) which get
an sg device file additionaly to their block device file. But it seems that
the statement about "document scanning" could need an update.


The main call for sg devices is ioclt(SG_IO) which performs a single SCSI
command transaction.
Since about 15 years it is possible to use it directly with a /dev/srX
device file. But a bug introduced in a late version of kernel 2.6 prevented
concurrent use of SG_IO on multiple sr devices. This ended with
  https://github.com/torvalds/linux/commit/51a8588
which i assume went into kernel version 5.6.
So with the currently released Debian versions, /dev/sgX is still of use
if there is more than one sr device.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#238021

On Mon 02 Aug 2021 at 13:21:22 +0200, Thomas Schmitt wrote:

> Hi,
> 
> Brian wrote:
> > Isn't /dev/sg0 the block device?
> 
> /dev/sgX are character devices.
> 
>   https://tldp.org/HOWTO/SCSI-Generic-HOWTO/intro.html
> says
>   "The driver's purpose is to allow SCSI commands to be sent directly to
>    SCSI devices. [...] Various specialized applications for writing
>    CD-Rs and document scanning use the sg driver."
> 
> This is still the case for optical drives (sr) and hard discs (sd) which get
> an sg device file additionaly to their block device file. But it seems that
> the statement about "document scanning" could need an update.
> 
> 
> The main call for sg devices is ioclt(SG_IO) which performs a single SCSI
> command transaction.
> Since about 15 years it is possible to use it directly with a /dev/srX
> device file. But a bug introduced in a late version of kernel 2.6 prevented
> concurrent use of SG_IO on multiple sr devices. This ended with
>   https://github.com/torvalds/linux/commit/51a8588
> which i assume went into kernel version 5.6.
> So with the currently released Debian versions, /dev/sgX is still of use
> if there is more than one sr device.

I misread sr0 as sg0; sorry to have put you to the trouble of posting.
On the bright side, you have helped clear up a misconception of mine.

-- 
Brian.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web