Another problem I ran into recently with the current major/minor
assignments.
i was attempting to put togeather an Informix server. I got a hardware
raid array with 54G of usable space. Informix prefers that this get cut
into 2G partitions (at least according to the informix DBA). This was not
possible to do without wither useing devfs or the developmental lvm code
David Lang
On Tue, 8 Jun 1999, Stephen Frost wrote:
>
> I think perhaps I'm asking the wrong question. The problem I
> have is the whole /dev/sd?? stuff. devfs allows for /dev/dsk/c0t0...
> kind of addressing, which to me makes alot more sense and is easier
> for me to work with. I don't see a way to do this (currently) in
> user space.
> Perhaps the problem is that SCSI major/minor numbers are
> not addressed in a way that I would find useful. Or are there other
> major/minor numbers addressed to scsi that are addressed wrt controller
> and target? Of course, if you then have to create all of them before
> booting because of bootstrapping issues, well, that's a heck of alot
> of devices...
>
> > As for dynamically pluggable devices, I guess the correct way to
> > handle these is via a daemon which invokes the script when new devices
> > are added or removed. That way we only have inodes for devices that
> > are actually present, not for ones which might turn up later.
>
> Hmm, I think maybe the question is, which way is it driven?
> Does the kernel automagically load the driver when the device is
> detected, or does the user attempt to access a device, which the kernel
> then has to go out and see if it exists (And if it can load a module
> for it). I've seen it both ways.
> If the kernel detects it, then having a user-space daemon
> running that handles the modprobe or whatnot and the creation of the
> devices will work (pcmcia seems to work in this way). However, what
> about devices that exist at all times in a system, but are compiled by
> the user as modules to perhaps save memory? Or the issue with printers
> and zip drives, where IIRC the user can rmmod and insmod the appropriate
> modules depending on which device he wants to talk to.
>
> I don't know if devfs handles all of these or not, I'm just
> trying to bring up points where it would be nice to have something that
> handles these different situations, and handles them in One way (if at
> all possible) to make it easier for the user.
>
> Stephen
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
"If users are made to understand that the system administrator's job is to
make computers run, and not to make them happy, they can, in fact, be made
happy most of the time. If users are allowed to believe that the system
administrator's job is to make them happy, they can, in fact, never be made
happy."
- -Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA '97)
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQEVAwUBN14bCz7msCGEppcbAQF0Tgf/cF9Jp2hOa72M6MFU0KbOQ/z4a9kpL1v7
4OgCh+hGB4vQv2R5LfYE0e6vW9iPpkFOHU3GSLJ9bEq0l+2eCjKyuDlP1+9MB+ZO
4TyQlzEHOW+u/DzCE/UbdZEyx917AD4Eu9ZD4/n/y1+MPz/9Szhh5NShsGYUSd48
nZD0ik9m2PzSqPSHo1DuBMWnodGT5f3YFCatd7hQAgSkVyeSAWOt+Fkhx2L3xk9o
c4qQUhLnoFWBavNTdkxZJwQ53pIK38eEuAq6dwY2LDhrN4ER/hERGtRWGDCUTkSU
zkC9evxh9q9elF6S/DBvDrz6ZmdE0cR7ZLdRo6NtXEe3F0KbR/ZPsw==
=EFe5
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/