Re: udev and devfs - The final word

From: Tyler Hall (tyler_hall_at_sympatico.ca)
Date: 01/02/04

  • Next message: Suparna Bhattacharya: "Re: [PATCH linux-2.6.1-rc1-mm1] filemap_fdatawait.patch"
    Date:	Fri, 02 Jan 2004 03:53:56 +0000
    To: rpc@cafe4111.org
    
    

    Since we're moving toward treating device numbers as unique handles for
    devices in a system, why can't we just dynamically allocate them like
    process ID's? As each device driver loads and registers with the kernel,
    it can request a device number and the kernel can assign the next
    available one.

    Tyler

    Rob wrote:

    >On Wednesday 31 December 2003 07:31 pm, Rob Love wrote:
    >
    ><snip>
    >
    >
    >>This is definitely an interesting problem space.
    >>
    >>I agree wrt just inventing consecutive numbers. If there was a nice way
    >>to trivially generate a random and unique number from some
    >>device-inherent information, that would be nice.
    >>
    >> Rob Love
    >>
    >>
    >
    >my first thought was hardware serial numbers, but i'm guessing they mostly
    >don't exist based on the discomfort caused by the pentium 3 serial number in
    >the past. my second thought was raw latency. in the real world, 2 identical
    >devices of any nature are going to respond electrically at different rates. i
    >kind of stole the concept from what i read about the i810 rng... quantum
    >differences can distinguish between 2 of anything, and based on the response
    >time, 'cookies' can be written out to keep them separately ID'd. some devices
    >will get slower over time, e.g. increasing error rates and aging silicon will
    >throw the 'cookie' off, so you'd re-calibrate every so often, like on a
    >reboot. those are rare for some of us ;)
    >
    >the big IF: can you measure that with enough precision to at least decrease
    >the probablity of collision?
    >
    >
    >

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Suparna Bhattacharya: "Re: [PATCH linux-2.6.1-rc1-mm1] filemap_fdatawait.patch"

    Relevant Pages

    • Re: udev and devfs - The final word
      ... On Wed, 2003-12-31 at 14:23, Greg KH wrote: ... > cookies and never need to be inspected except in very small parts of ... kernel can pull that number from anywhere, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 1/3] 2.6.8-rc4-mm1 - Fix UML build
      ... can access them all, and initialized data all before uninitialized, so ... SYMLINKS:= $,$/$f) ... semaphore.c-dir = kernel ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
      ... > rebooted to a kernel that doesn't have the RT-preempt patch but ... getting a very verbose running trail, almost like an strace output, ... Copyright 2005 by Maurice Eugene Heskett, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • RE: Error mounting root fs on 72:01 using Promise FastTrak TX2000 (PDC20271)
      ... > Now I'm sucessfully booting my system with the 2.4.23 kernel using ... I think it's when the ATARAID driver is about to fire up. ... > the hard drives since this is the only thing that has changed. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Linux 2.4.30-rc3 md/ext3 problems
      ... you have your root on ext3 on top of soft raid1 consisting in ... two IDE disks, which works in 2.4.21 but not on 2.4.30-rc3, that's ... top of scsi and with kernel 2.4.27, so there's not much to compare... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)

  • Quantcast