udev-ish replacement for hal-cups-utils?

Tim Waugh twaugh at redhat.com
Wed Jul 22 03:44:07 PDT 2009


On Wed, 2009-07-22 at 03:53 +0200, Till Kamppeter wrote:
> Here I suggest a samll change. If there are both URIs which fit with 
> serial number and which fit without serial number, take them all 
> together into the valid URI list (instead of dropping all non-serial if 
> one with serial is found, to assure the disabling and re-enabling of 
> existing queues.

Yes, OK, that makes sense.

> URI selection for new queues should only be made based 
> on how well the URI fits to the hardware, for example if there is an 
> HPLIP URI, prefer using it instead of the plain CUPS "usb" URI.

Ideally, of course, hpijs would use the back-channel/side-channel
support present in the CUPS backend.  Then it would automatically gain
support for USB, parallel port and network devices, allowing a whole
load of code to be removed from HPLIP including the hp backend itself.

It seems to only require looking at the Device ID, which can be fetched
using the side-channel command CUPS_SC_CMD_GET_DEVICE_ID.

For the time being, I'll get udev-configure-printer to prefer the hp
backend over the usb backend, as the above is not likely to happen
without someone making a large patch.

> In general, blank lines (whitespace-only lines) should be ignored.

This is not a user-modifiable file.  There won't be blank lines.

> The URI problem is solved, the problem that HPLIP replaces all 
> manufacturer names "hp", "hewlett-packard", and "Hewlett-Packard" 
> (case-insensitive match) by "HP" still requires this ugly patch:

No, it requires HPLIP to report the correct device-id for the device.

Look, here is a patch to actually do that:

http://cvs.fedoraproject.org/viewvc/devel/hplip/hplip-device-id.patch?view=markup

> I have already tried opening the URI file for reading and writing 
> ("w+"), lock it with a write lock (exclusive), read it, process data, 
> write it, and then close it. Problem is that I do not succeed to 
> truncate the file to zero before writing it.

Did you try using ftruncate()? ;-)  Fixed.

> The following patch adds better error reporting and also fixes the 
> problem that if the URI map empties (all printers disconnected), the 
> line for the last printer still remains in the URI map file. It should 
> go away, too.

I don't see that problem here.  More comments about this patch:

>     if (fd == -1)
> -    return map;
> +    {
> +      syslog (LOG_ERR, "Unable to open for reading " USB_URI_MAP);
> +      return map;
> +    }

This is not an error.

>     fclose (f);
> +  close(fd);
>     return map;

The fclose call closes the underlying file descriptor.

> -  for (each = map; each; each = each->next)
> +  if (map != NULL)
>       {
> -      size_t i;
> -      fprintf (f, "%s\t%s", each->devpath, each->uris.uri[0]);
> -      for (i = 1; i < each->uris.n_uris; i++)
> -	fprintf (f, "\t%s", each->uris.uri[i]);
> -      fwrite ("\n", 1, 1, f);
> +      for (each = map; each; each = each->next)
> +	{
> +	  size_t i;
> +	  fprintf (f, "%s\t%s", each->devpath, each->uris.uri[0]);
> +	  for (i = 1; i < each->uris.n_uris; i++)
> +	    fprintf (f, "\t%s", each->uris.uri[i]);
> +	  fwrite ("\n", 1, 1, f);
> +	}
> +      fclose (f);
> +      close(fd);
>       }
> -  fclose (f);
> +  else
> +    unlink(USB_URI_MAP);
>   }

The 'for (each = map; each; ...' bit handled map==NULL without any
problems.  Not sure what problem you are trying to solve there.

> 2. This patch for the "remove" process makes parents and children of the 
> original device path which was used for the "add" process also disable 
> the queues. This should make the "remove" process more reliable, 
> especially on systems where the usblp module is still in use.

The usb-uris map always contains the devpath of the ("usb","usb_device")
device.  Did you see an actual problem here?

Tim.
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/devkit-devel/attachments/20090722/43fa82ec/attachment.pgp 


More information about the devkit-devel mailing list