Updating PCI vendors database

2011-04-04 Thread Philip Paeps
It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as
far as I can tell) has become rather stale.  We also appear to be tracking
sources which no longer exist.

Would anyone object if I updated this list to source the same database used by
Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids?

It helps that our pciconf looks to be compatible with that format.  We just
ignore subvendor and subdevice, but it doesn't appear to matter that the file
contains this information.

I could cull the subvendor/subdevice from the list though.

Any views?

Reason I'm looking into this is because one of my customers would like their
name to be correct when I import the driver I've been working on for them. :)

 - Philip

-- 
Philip PaepsPlease don't Cc me, I am
phi...@freebsd.org   subscribed to the list.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Updating PCI vendors database

2011-04-04 Thread Philip Paeps
On 2011-04-04 16:10:16 (+0200), Philip Paeps phi...@freebsd.org wrote:
 Would anyone object if I updated this list to source the same database used
 by Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids?

It occurs to me that people would want to verify that this list does actually
work and that we gain (rather than lose) coverage from it.

A sanity test I've run on a couple of machines:

  % fetch http://pciids.sourceforge.net/v2.2/pci.ids
  % pciconf -lv  /tmp/pciconflv.old
  % PCICONF_VENDOR_DATABASE=pci.ids pciconf -lv /tmp/pciconflv.new
  % diff -u /tmp/pciconflv.old /tmp/pciconflv.new

In all cases I've seen so far, the new list yields better (more correct and up
to date) results than the exising list.  In no cases has pciconf complained
about the new list.

 - Philip

-- 
Philip PaepsPlease don't Cc me, I am
phi...@freebsd.org   subscribed to the list.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Updating PCI vendors database

2011-04-04 Thread Philip Paeps
On 2011-04-04 07:31:53 (-0700), Garrett Cooper gcoo...@freebsd.org wrote:
 On Mon, Apr 4, 2011 at 7:19 AM, Philip Paeps phi...@freebsd.org wrote:
  On 2011-04-04 16:10:16 (+0200), Philip Paeps phi...@freebsd.org wrote:
  Would anyone object if I updated this list to source the same database used
  by Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids?
 
  It occurs to me that people would want to verify that this list does 
  actually
  work and that we gain (rather than lose) coverage from it.
 
  A sanity test I've run on a couple of machines:
 
   % fetch http://pciids.sourceforge.net/v2.2/pci.ids
   % pciconf -lv  /tmp/pciconflv.old
   % PCICONF_VENDOR_DATABASE=pci.ids pciconf -lv /tmp/pciconflv.new
   % diff -u /tmp/pciconflv.old /tmp/pciconflv.new
 
  In all cases I've seen so far, the new list yields better (more correct and 
  up
  to date) results than the exising list.  In no cases has pciconf complained
  about the new list.
 
 I've copy-pasted the discussion I brought this up to Warner/Brooks
 several months ago for review.

I think at that point, the lists we're currently sourcing still existed.  As
of this morning, I don't seem to be able to find Craig Hart's list of PCI IDs
anywhere on the net.  It's certainly no long available at the address listed
in the source tree.

 The big problem is that the descriptions with the previous source and the
 new source clash, so this would cause a huge amount of diff churn;

This would be a problem I agree, but not a huge one.  If the churn would be
too large, I would be hesitant to push this to any stable branches.  But I
don't think the churn should be a problem for HEAD.  It doesn't look to me
like the churn is too large on the machines I've used it on.

Generally, the changes I've seen is devices which lacked a device description
now have one, and devices which had a wrong or incomplete description now have
a complete and (as far as I can tell) correct one.  This feels like an
improvement to me. :)

 plus I think there are a few entries missing from each area (at least there
 were the last time I looked -- maybe our pci_vendors is more spartan than
 the new source is today).

The new list is much more complete than the list we have currently.  For one
thing, it also includes subvendors and subdevices, which the current list
lacks.  Our pciconf doesn't care about those currently, but could be made to
care.

I also don't think we should underestimate the value of sharing a list with
Linux (especially if the licence on the list is friendly to sharing it) and
potentially other operating system vendors.

 - Philip

-- 
Philip PaepsPlease don't Cc me, I am
phi...@freebsd.org   subscribed to the list.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Updating PCI vendors database

2011-04-04 Thread Philip Paeps
On 2011-04-04 17:39:22 (+0300), Andriy Gapon a...@freebsd.org wrote:
 on 04/04/2011 17:10 Philip Paeps said the following:
  It looks like our /usr/share/misc/pci_vendors list (used only by pciconf as
  far as I can tell) has become rather stale.  We also appear to be tracking
  sources which no longer exist.
  
  Would anyone object if I updated this list to source the same database used 
  by
  Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids?
  
  It helps that our pciconf looks to be compatible with that format.  We just
  ignore subvendor and subdevice, but it doesn't appear to matter that the 
  file
  contains this information.
  
  I could cull the subvendor/subdevice from the list though.
  
  Any views?
  
  Reason I'm looking into this is because one of my customers would like their
  name to be correct when I import the driver I've been working on for them. 
  :)
 
 This is just for your information:
 http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577
 Maybe you'll find something useful there.

Thanks.  I've just read through that discussion.  It doesn't look like there
were any serious objections to pulling in the new list, other than verifying
that the new list contains all the entries the current list contains.

I am not entirely sure what the little side-discussion about using # instead
of ; as a comment marker is about.  It looks to me like the pci.ids file Just
Works[tm] with our pciconf(8).  Maybe Garrett can elaborate on that?

I think we should just go with the new list, but I'll hold off for a bit to
let others object. ;)

 - Philip

-- 
Philip PaepsPlease don't Cc me, I am
phi...@freebsd.org   subscribed to the list.

  You can't fix it if it ain't broke.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Updating PCI vendors database

2011-04-04 Thread Philip Paeps
On 2011-04-04 08:51:03 (-0700), Garrett Cooper yaneg...@gmail.com wrote:
 On Mon, Apr 4, 2011 at 7:57 AM, Philip Paeps phi...@freebsd.org wrote:
  On 2011-04-04 17:39:22 (+0300), Andriy Gapon a...@freebsd.org wrote:
  on 04/04/2011 17:10 Philip Paeps said the following:
   Would anyone object if I updated this list to source the same database
   used by Linux distributions at
   http://pciids.sourceforge.net/v2.2/pci.ids?
  
   It helps that our pciconf looks to be compatible with that format.  We
   just ignore subvendor and subdevice, but it doesn't appear to matter
   that the file contains this information.
   [...]
 
  This is just for your information:
  http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577
  Maybe you'll find something useful there.
 
  Thanks.  I've just read through that discussion.  It doesn't look like
  there were any serious objections to pulling in the new list, other than
  verifying that the new list contains all the entries the current list
  contains.
 
  I am not entirely sure what the little side-discussion about using #
  instead of ; as a comment marker is about.  It looks to me like the
  pci.ids file Just Works[tm] with our pciconf(8).  Maybe Garrett can
  elaborate on that?
 
 Well, close. You can substitute the hashes with semicolons, but you
 need to get rid of subvendor / subdevice.

The presence of the subvendor/subdevice entries doesn't appear to affect the
correctness of the output on the machines I've tested it on.  Cursorily
reading through the pciconf(8) source code suggests it ignores that data (and
as it happens the presence of subvendors and subdevices).

I think the most correct thing to do would be to teach pciconf(8) about
subvendors and subdevices and pull in the new list as-is.  I'll take a look
at adding support for that later today.  It shouldn't be much work.

 Setting PCICONF_VENDOR_DATABASE to pci.ids worked, but all the items on my
 box are different in the new file (all device descriptions, but also some of
 the vendor descriptions dealing with my nVidia card, Realtek NIC, and LSI
 card) [it would be interesting to see who's correct in terms of corporation
 branding :)..]. So this definitely isn't MFC-able :).

It doesn't look like they're fundamentally different through.  The strings
changed, but still seem to be describing the same devices.

I'm happy to agree that this isn't MFC-able.

  I think we should just go with the new list, but I'll hold off for a bit
  to let others object. ;)
 
 +1, just for the fact that our sources are becoming stale. I wonder though
 what other OSes like NetBSD/OpenBSD/[Open]Solaris/IlluminOS use however for
 tracking PCI IDs, as the sources for pci.ids aren't necessarily the vendor
 itself and in some cases are end-users. I thought some of our other sources
 were based on data provided by vendors.

A comment from jfv@ in the thread from a few months ago, suggests that at
least Intel contributes directly to the pci.ids list.  One measurement isn't
a valid statistic though.

 - Philip

-- 
Philip PaepsPlease don't Cc me, I am
phi...@freebsd.org   subscribed to the list.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Updating PCI vendors database

2011-04-04 Thread Philip Paeps
On 2011-04-04 17:44:29 (+0200), Alex Dupre a...@freebsd.org wrote:
 Philip Paeps ha scritto:
  This is just for your information:
  http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577
  Maybe you'll find something useful there.
 
  Thanks.  I've just read through that discussion.  It doesn't look like there
  were any serious objections to pulling in the new list, other than 
  verifying
  that the new list contains all the entries the current list contains.
 
 The discussion went on privately (dunno why) beetween John, Warner, Brooks,
 me and a few others. I suggest you to contact John Baldwin before taking
 actions, I've updated also the merged lists.

Thanks.  I'll talk to them.

 - Philip

-- 
Philip PaepsPlease don't Cc me, I am
phi...@freebsd.org   subscribed to the list.

  I thought that said Windows has been installed for your safety.
-- SlimeyPete, looking at safety signs on a train
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Updating PCI vendors database

2011-04-04 Thread Philip Paeps
On 2011-04-04 11:04:38 (-0700), Doug Barton do...@freebsd.org wrote:
 On 04/04/2011 07:10, Philip Paeps wrote:
  It looks like our /usr/share/misc/pci_vendors list (used only by pciconf
  as far as I can tell) has become rather stale.  We also appear to be
  tracking sources which no longer exist.
 
  Would anyone object if I updated this list to source the same database
  used by Linux distributions at http://pciids.sourceforge.net/v2.2/pci.ids?
 
  It helps that our pciconf looks to be compatible with that format.  We
  just ignore subvendor and subdevice, but it doesn't appear to matter that
  the file contains this information.
 
  I could cull the subvendor/subdevice from the list though.
 
  Any views?
 
 Having read this thread, and the last one, my opinion is, let's do it
 already. :) 

I'll wait a little longer for more comments but then: yes, I'll go and do it.

 Repo churn should not, under any circumstances, be a consideration in
 technical improvements. I agree with those who have said that the new list
 should be confirmed to be a superset of the old, and anything missing should
 be merged in. Checking with Jack about Intel stuff is also reasonable, as
 would be cross-checking with what NetBSD and OpenBSD are doing (and perhaps
 communicating with them about your work).
 
 So, not a slam-dunk, but definitely a clear path forward. Oh, and I
 personally don't see a problem with MFC'ing this, but I'm willing to be
 convinced.

I was thinking of putting it in head and waiting a good while for the
screaming to subside and the fires to go out before raising the idea of
merging it to stable.

Barring any clear counterindications, I'll just do this in the next day or
so.

 - Philip

-- 
Philip PaepsPlease don't Cc me, I am
phi...@freebsd.org   subscribed to the list.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: crypto(9) choose another driver if we cannot open a session on it

2008-12-08 Thread Philip Paeps
On 2008-12-07 22:45:51 (+0100), Patrick Lamaizière [EMAIL PROTECTED] wrote:
 I wrote a small patch to allow the crypto framework to choose another
 cryptographic driver if we cannot open a session on the driver.

Very cool. :-)  I've been hacking on this too, mainly to get rid of the code
duplication that currently exists.

 That should not break anything. It would be nice to test it on a box with a
 Geode LX CPU and a crypto device like a VPN1411 card.  I don't have the
 hardware but I've checked that we revert to the cryptosoft driver when using
 ipsec and glxsb with AES key's length != 128 bits.

I'll test that tonight.  I think I've got a hifn card hiding somewhere near a
soekris.

Thanks!

 - Philip

-- 
Philip PaepsPlease don't Cc me, I am
[EMAIL PROTECTED]   subscribed to the list.

  Maybe you should loosen her clothing or something.
  -- Gaspode the wonder dog
 (Terry Pratchett, Moving Pictures)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Csup cvsmode build discussion

2008-01-16 Thread Philip Paeps
On 2008-01-16 10:33:02 (+0100), Ulf Lilleengen [EMAIL PROTECTED] wrote:
 Now, the base system already have flex, but the flex version in base is 
 heavily
 outdated (version 2.5.4 versus 2.5.34 in ports) and does not support 
 reentrancy.
 Is there a reason why it's outdated? What I can think of is that it is either
 unmaintained, or that developers want it to disappear from base.

I think it's just unmaintained in base ...  I wonder what it would take to
update it.  /me takes a look

 - Philip

-- 
Philip PaepsPlease don't Cc me, I am
[EMAIL PROTECTED]   subscribed to the list.

  Da da da da da da da da da, yeah yeah yeah yeah,
  da da da da da da da da da, yeah yeah yeah yeah...
-- Various people singing along to Man On The Moon without knowing
   the words
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Csup cvsmode build discussion

2008-01-16 Thread Philip Paeps
On 2008-01-16 16:06:56 (+0100), Ulf Lilleengen [EMAIL PROTECTED] wrote:
 However, this might only fix the issue with yacc if I'm thinking correctly,
 because the lexer also needs to be told about this for reentrancy. (But
 perhaps a much smaller problem since it's a matter of updating the lex
 version in base). 

I found that updating the lex in base was surprisingly easy. :-)  I'll clean
up my patches and post them for review later this evening.

 - Philip

-- 
Philip PaepsPlease don't Cc me, I am
[EMAIL PROTECTED]   subscribed to the list.

  One day a tortoise will learn how to fly.
  -- (Terry Pratchett, Small Gods)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: AoE for FreeBSD

2004-11-11 Thread Philip Paeps
On 2004-11-10 15:36:26 (-0500), Sam Hopkins [EMAIL PROTECTED] wrote:
 Just a quick note to mention that I've added AoE support to FreeBSD 4.10, 
 5.3, and 6.0.
 Patches are available at http://www.coraid.com/support/freebsd.
 
 If anyone knows where else I could announce this, I'd appreciate it.

Is someone planning to commit this?  This is great stuff :-)

 - Philip

-- 
Philip PaepsPlease don't Cc me, I am
[EMAIL PROTECTED]   subscribed to the list.

  No one keeps a record of decisions you could have made
  but didn't.  Everyone keeps a records of your bad ones.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Anyone where to get a signed SSL certificate cheap?

2003-02-06 Thread Philip Paeps
On 2003-02-05 18:17:24 (+), Josef Karthauser [EMAIL PROTECTED] wrote:
 I need to obtain a certificate to use on my openssl/apache web server, but
 looking at Verisign and Thawte it appears that they're charging a lot of
 money ($450) per year for one!  Does anyone know where I can get one
 cheaper?  Last time I bought I'm sure that they were only $100/yr each.

There are quite a few places willing to cell you certificates for $100 or
less, but the problem is that those usually cause big red error-messages to
pop up on the users' screen.

I buy my certificates from GlobalSign http://www.globalsign.com/, which
sells them to me for ¤175/yr.  Their root certificate is recognised by most
browsers I've encountered.

 p.s. yes, I know that I could self-sign, but this is for an ecommerce system
 and I'd prefer our customer's customers not to have to ask themselves why
 the certificate is in our name and not our customer's! :)

You'd have the same problem with the $100/yr certificates.  Most browsers
don't recognise them (bloody monopoly :-/) and pop up doomsday warnings...

 - Philip

-- 
Philip Paeps  Please don't CC me, I am
[EMAIL PROTECTED]   subscribed to the list.

  BOFH Excuse #199:
the curls in your keyboard cord are losing electricity.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Cardreaders and touchscreens?

2002-06-10 Thread Philip Paeps

Hi there -

One of my clients would like me to hack together an application involving a
cardreader and a touchscreen.  How would I deal with these two rather 'odd'
pieces of hardware.  I didn't have any say in the purchasing of the
touchscreen, but I suppose that shouldn't give me any trouble?  It's just a
keyboard/mouse combination in a strange shape, as I see it?

The cardreader is another story.  I'm free in choosing one which I can get to
work.  Does anyone have any experience with these things under FreeBSD?  Any
brands/types from which I *really* should stay away?

Thanks for any info!

 - Philip

-- 
Philip Paeps
[EMAIL PROTECTED]
http://www.paeps.cx/

+32 486 114 720

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message