2002-04-21 15:47:03 +00:00
|
|
|
/*-
|
2000-08-20 21:34:39 +00:00
|
|
|
* Copyright (c) 1992, 1993
|
|
|
|
|
* The Regents of the University of California. All rights reserved.
|
|
|
|
|
* Copyright (c) 2000
|
|
|
|
|
* Poul-Henning Kamp. All rights reserved.
|
2002-07-17 01:46:48 +00:00
|
|
|
* Copyright (c) 2002
|
|
|
|
|
* Dima Dorfman. All rights reserved.
|
2000-08-20 21:34:39 +00:00
|
|
|
*
|
|
|
|
|
* This code is derived from software donated to Berkeley by
|
|
|
|
|
* Jan-Simon Pendry.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
|
* 2. Neither the name of the University nor the names of its contributors
|
|
|
|
|
* may be used to endorse or promote products derived from this software
|
|
|
|
|
* without specific prior written permission.
|
|
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
|
*
|
|
|
|
|
* @(#)kernfs.h 8.6 (Berkeley) 3/29/95
|
|
|
|
|
* From: FreeBSD: src/sys/miscfs/kernfs/kernfs.h 1.14
|
|
|
|
|
*
|
|
|
|
|
* $FreeBSD$
|
|
|
|
|
*/
|
|
|
|
|
|
2000-09-06 11:26:43 +00:00
|
|
|
#ifndef _FS_DEVFS_DEVFS_H_
|
2002-04-21 15:47:03 +00:00
|
|
|
#define _FS_DEVFS_DEVFS_H_
|
2000-08-20 21:34:39 +00:00
|
|
|
|
2002-07-17 01:46:48 +00:00
|
|
|
#define DEVFS_MAGIC 0xdb0a087a
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Identifiers. The ruleset and rule numbers are 16-bit values. The
|
|
|
|
|
* "rule ID" is a combination of the ruleset and rule number; it
|
|
|
|
|
* should be able to univocally describe a rule in the system. In
|
|
|
|
|
* this implementation, the upper 16 bits of the rule ID is the
|
|
|
|
|
* ruleset number; the lower 16 bits, the rule number within the
|
|
|
|
|
* aforementioned ruleset.
|
|
|
|
|
*/
|
|
|
|
|
typedef uint16_t devfs_rnum;
|
|
|
|
|
typedef uint16_t devfs_rsnum;
|
|
|
|
|
typedef uint32_t devfs_rid;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Identifier manipulators.
|
|
|
|
|
*/
|
|
|
|
|
#define rid2rsn(rid) ((rid) >> 16)
|
|
|
|
|
#define rid2rn(rid) ((rid) & 0xffff)
|
|
|
|
|
#define mkrid(rsn, rn) ((rn) | ((rsn) << 16))
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Plain DEVFS rule. This gets shared between kernel and userland
|
|
|
|
|
* verbatim, so it shouldn't contain any pointers or other kernel- or
|
|
|
|
|
* userland-specific values.
|
|
|
|
|
*/
|
|
|
|
|
struct devfs_rule {
|
|
|
|
|
uint32_t dr_magic; /* Magic number. */
|
|
|
|
|
devfs_rid dr_id; /* Identifier. */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Conditions under which this rule should be applied. These
|
|
|
|
|
* are ANDed together since OR can be simulated by using
|
|
|
|
|
* multiple rules. dr_icond determines which of the other
|
|
|
|
|
* variables we should process.
|
|
|
|
|
*/
|
|
|
|
|
int dr_icond;
|
|
|
|
|
#define DRC_DSWFLAGS 0x001
|
|
|
|
|
#define DRC_PATHPTRN 0x002
|
|
|
|
|
int dr_dswflags; /* cdevsw flags to match. */
|
|
|
|
|
#define DEVFS_MAXPTRNLEN 200
|
|
|
|
|
char dr_pathptrn[DEVFS_MAXPTRNLEN]; /* Pattern to match path. */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Things to change. dr_iacts determines which of the other
|
|
|
|
|
* variables we should process.
|
|
|
|
|
*/
|
|
|
|
|
int dr_iacts;
|
|
|
|
|
#define DRA_BACTS 0x001
|
2002-07-28 06:57:57 +00:00
|
|
|
#define DRA_UID 0x002
|
2002-07-17 01:46:48 +00:00
|
|
|
#define DRA_GID 0x004
|
|
|
|
|
#define DRA_MODE 0x008
|
|
|
|
|
#define DRA_INCSET 0x010
|
|
|
|
|
int dr_bacts; /* Boolean (on/off) action. */
|
|
|
|
|
#define DRB_HIDE 0x001 /* Hide entry (DE_WHITEOUT). */
|
|
|
|
|
#define DRB_UNHIDE 0x002 /* Unhide entry. */
|
|
|
|
|
uid_t dr_uid;
|
|
|
|
|
gid_t dr_gid;
|
|
|
|
|
mode_t dr_mode;
|
|
|
|
|
devfs_rsnum dr_incset; /* Included ruleset. */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Rule-related ioctls.
|
|
|
|
|
*/
|
|
|
|
|
#define DEVFSIO_RADD _IOWR('D', 0, struct devfs_rule)
|
|
|
|
|
#define DEVFSIO_RDEL _IOW('D', 1, devfs_rid)
|
|
|
|
|
#define DEVFSIO_RAPPLY _IOW('D', 2, struct devfs_rule)
|
|
|
|
|
#define DEVFSIO_RAPPLYID _IOW('D', 3, devfs_rid)
|
|
|
|
|
#define DEVFSIO_RGETNEXT _IOWR('D', 4, struct devfs_rule)
|
|
|
|
|
|
|
|
|
|
#define DEVFSIO_SUSE _IOW('D', 10, devfs_rsnum)
|
|
|
|
|
#define DEVFSIO_SAPPLY _IOW('D', 11, devfs_rsnum)
|
|
|
|
|
#define DEVFSIO_SGETNEXT _IOWR('D', 12, devfs_rsnum)
|
|
|
|
|
|
|
|
|
|
/* XXX: DEVFSIO_RS_GET_INFO for refcount, active if any, etc. */
|
|
|
|
|
|
|
|
|
|
#ifdef _KERNEL
|
2000-08-20 21:34:39 +00:00
|
|
|
|
2002-04-21 15:47:03 +00:00
|
|
|
#ifdef MALLOC_DECLARE
|
2000-08-20 21:34:39 +00:00
|
|
|
MALLOC_DECLARE(M_DEVFS);
|
2002-04-21 15:47:03 +00:00
|
|
|
#endif
|
2000-08-20 21:34:39 +00:00
|
|
|
|
|
|
|
|
struct devfs_dirent {
|
Rewamp DEVFS internals pretty severely [1].
Give DEVFS a proper inode called struct cdev_priv. It is important
to keep in mind that this "inode" is shared between all DEVFS
mountpoints, therefore it is protected by the global device mutex.
Link the cdev_priv's into a list, protected by the global device
mutex. Keep track of each cdev_priv's state with a flag bit and
of references from mountpoints with a dedicated usecount.
Reap the benefits of much improved kernel memory allocator and the
generally better defined device driver APIs to get rid of the tables
of pointers + serial numbers, their overflow tables, the atomics
to muck about in them and all the trouble that resulted in.
This makes RAM the only limit on how many devices we can have.
The cdev_priv is actually a super struct containing the normal cdev
as the "public" part, and therefore allocation and freeing has moved
to devfs_devs.c from kern_conf.c.
The overall responsibility is (to be) split such that kern/kern_conf.c
is the stuff that deals with drivers and struct cdev and fs/devfs
handles filesystems and struct cdev_priv and their private liason
exposed only in devfs_int.h.
Move the inode number from cdev to cdev_priv and allocate inode
numbers properly with unr. Local dirents in the mountpoints
(directories, symlinks) allocate inodes from the same pool to
guarantee against overlaps.
Various other fields are going to migrate from cdev to cdev_priv
in the future in order to hide them. A few fields may migrate
from devfs_dirent to cdev_priv as well.
Protect the DEVFS mountpoint with an sx lock instead of lockmgr,
this lock also protects the directory tree of the mountpoint.
Give each mountpoint a unique integer index, allocated with unr.
Use it into an array of devfs_dirent pointers in each cdev_priv.
Initially the array points to a single element also inside cdev_priv,
but as more devfs instances are mounted, the array is extended with
malloc(9) as necessary when the filesystem populates its directory
tree.
Retire the cdev alias lists, the cdev_priv now know about all the
relevant devfs_dirents (and their vnodes) and devfs_revoke() will
pick them up from there. We still spelunk into other mountpoints
and fondle their data without 100% good locking. It may make better
sense to vector the revoke event into the tty code and there do a
destroy_dev/make_dev on the tty's devices, but that's for further
study.
Lots of shuffling of stuff and churn of bits for no good reason[2].
XXX: There is still nothing preventing the dev_clone EVENTHANDLER
from being invoked at the same time in two devfs mountpoints. It
is not obvious what the best course of action is here.
XXX: comment out an if statement that lost its body, until I can
find out what should go there so it doesn't do damage in the meantime.
XXX: Leave in a few extra malloc types and KASSERTS to help track
down any remaining issues.
Much testing provided by: Kris
Much confusion caused by (races in): md(4)
[1] You are not supposed to understand anything past this point.
[2] This line should simplify life for the peanut gallery.
2005-09-19 19:56:48 +00:00
|
|
|
struct cdev_priv *de_cdp;
|
2004-02-15 21:43:08 +00:00
|
|
|
int de_inode;
|
|
|
|
|
int de_flags;
|
2001-05-23 17:48:20 +00:00
|
|
|
#define DE_WHITEOUT 0x1
|
2000-08-24 15:36:55 +00:00
|
|
|
#define DE_DOT 0x2
|
|
|
|
|
#define DE_DOTDOT 0x4
|
2004-02-15 21:43:08 +00:00
|
|
|
struct dirent *de_dirent;
|
2000-08-20 21:34:39 +00:00
|
|
|
TAILQ_ENTRY(devfs_dirent) de_list;
|
2000-08-24 15:36:55 +00:00
|
|
|
TAILQ_HEAD(, devfs_dirent) de_dlist;
|
2004-02-15 21:43:08 +00:00
|
|
|
struct devfs_dirent *de_dir;
|
|
|
|
|
int de_links;
|
|
|
|
|
mode_t de_mode;
|
|
|
|
|
uid_t de_uid;
|
|
|
|
|
gid_t de_gid;
|
|
|
|
|
struct label *de_label;
|
|
|
|
|
struct timespec de_atime;
|
|
|
|
|
struct timespec de_mtime;
|
|
|
|
|
struct timespec de_ctime;
|
|
|
|
|
struct vnode *de_vnode;
|
|
|
|
|
char *de_symlink;
|
2000-08-20 21:34:39 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct devfs_mount {
|
Rewamp DEVFS internals pretty severely [1].
Give DEVFS a proper inode called struct cdev_priv. It is important
to keep in mind that this "inode" is shared between all DEVFS
mountpoints, therefore it is protected by the global device mutex.
Link the cdev_priv's into a list, protected by the global device
mutex. Keep track of each cdev_priv's state with a flag bit and
of references from mountpoints with a dedicated usecount.
Reap the benefits of much improved kernel memory allocator and the
generally better defined device driver APIs to get rid of the tables
of pointers + serial numbers, their overflow tables, the atomics
to muck about in them and all the trouble that resulted in.
This makes RAM the only limit on how many devices we can have.
The cdev_priv is actually a super struct containing the normal cdev
as the "public" part, and therefore allocation and freeing has moved
to devfs_devs.c from kern_conf.c.
The overall responsibility is (to be) split such that kern/kern_conf.c
is the stuff that deals with drivers and struct cdev and fs/devfs
handles filesystems and struct cdev_priv and their private liason
exposed only in devfs_int.h.
Move the inode number from cdev to cdev_priv and allocate inode
numbers properly with unr. Local dirents in the mountpoints
(directories, symlinks) allocate inodes from the same pool to
guarantee against overlaps.
Various other fields are going to migrate from cdev to cdev_priv
in the future in order to hide them. A few fields may migrate
from devfs_dirent to cdev_priv as well.
Protect the DEVFS mountpoint with an sx lock instead of lockmgr,
this lock also protects the directory tree of the mountpoint.
Give each mountpoint a unique integer index, allocated with unr.
Use it into an array of devfs_dirent pointers in each cdev_priv.
Initially the array points to a single element also inside cdev_priv,
but as more devfs instances are mounted, the array is extended with
malloc(9) as necessary when the filesystem populates its directory
tree.
Retire the cdev alias lists, the cdev_priv now know about all the
relevant devfs_dirents (and their vnodes) and devfs_revoke() will
pick them up from there. We still spelunk into other mountpoints
and fondle their data without 100% good locking. It may make better
sense to vector the revoke event into the tty code and there do a
destroy_dev/make_dev on the tty's devices, but that's for further
study.
Lots of shuffling of stuff and churn of bits for no good reason[2].
XXX: There is still nothing preventing the dev_clone EVENTHANDLER
from being invoked at the same time in two devfs mountpoints. It
is not obvious what the best course of action is here.
XXX: comment out an if statement that lost its body, until I can
find out what should go there so it doesn't do damage in the meantime.
XXX: Leave in a few extra malloc types and KASSERTS to help track
down any remaining issues.
Much testing provided by: Kris
Much confusion caused by (races in): md(4)
[1] You are not supposed to understand anything past this point.
[2] This line should simplify life for the peanut gallery.
2005-09-19 19:56:48 +00:00
|
|
|
u_int dm_idx;
|
2004-02-15 21:43:08 +00:00
|
|
|
struct mount *dm_mount;
|
|
|
|
|
struct devfs_dirent *dm_rootdir;
|
|
|
|
|
unsigned dm_generation;
|
Rewamp DEVFS internals pretty severely [1].
Give DEVFS a proper inode called struct cdev_priv. It is important
to keep in mind that this "inode" is shared between all DEVFS
mountpoints, therefore it is protected by the global device mutex.
Link the cdev_priv's into a list, protected by the global device
mutex. Keep track of each cdev_priv's state with a flag bit and
of references from mountpoints with a dedicated usecount.
Reap the benefits of much improved kernel memory allocator and the
generally better defined device driver APIs to get rid of the tables
of pointers + serial numbers, their overflow tables, the atomics
to muck about in them and all the trouble that resulted in.
This makes RAM the only limit on how many devices we can have.
The cdev_priv is actually a super struct containing the normal cdev
as the "public" part, and therefore allocation and freeing has moved
to devfs_devs.c from kern_conf.c.
The overall responsibility is (to be) split such that kern/kern_conf.c
is the stuff that deals with drivers and struct cdev and fs/devfs
handles filesystems and struct cdev_priv and their private liason
exposed only in devfs_int.h.
Move the inode number from cdev to cdev_priv and allocate inode
numbers properly with unr. Local dirents in the mountpoints
(directories, symlinks) allocate inodes from the same pool to
guarantee against overlaps.
Various other fields are going to migrate from cdev to cdev_priv
in the future in order to hide them. A few fields may migrate
from devfs_dirent to cdev_priv as well.
Protect the DEVFS mountpoint with an sx lock instead of lockmgr,
this lock also protects the directory tree of the mountpoint.
Give each mountpoint a unique integer index, allocated with unr.
Use it into an array of devfs_dirent pointers in each cdev_priv.
Initially the array points to a single element also inside cdev_priv,
but as more devfs instances are mounted, the array is extended with
malloc(9) as necessary when the filesystem populates its directory
tree.
Retire the cdev alias lists, the cdev_priv now know about all the
relevant devfs_dirents (and their vnodes) and devfs_revoke() will
pick them up from there. We still spelunk into other mountpoints
and fondle their data without 100% good locking. It may make better
sense to vector the revoke event into the tty code and there do a
destroy_dev/make_dev on the tty's devices, but that's for further
study.
Lots of shuffling of stuff and churn of bits for no good reason[2].
XXX: There is still nothing preventing the dev_clone EVENTHANDLER
from being invoked at the same time in two devfs mountpoints. It
is not obvious what the best course of action is here.
XXX: comment out an if statement that lost its body, until I can
find out what should go there so it doesn't do damage in the meantime.
XXX: Leave in a few extra malloc types and KASSERTS to help track
down any remaining issues.
Much testing provided by: Kris
Much confusion caused by (races in): md(4)
[1] You are not supposed to understand anything past this point.
[2] This line should simplify life for the peanut gallery.
2005-09-19 19:56:48 +00:00
|
|
|
struct sx dm_lock;
|
2004-02-15 21:43:08 +00:00
|
|
|
devfs_rsnum dm_ruleset;
|
2000-08-20 21:34:39 +00:00
|
|
|
};
|
|
|
|
|
|
Rewamp DEVFS internals pretty severely [1].
Give DEVFS a proper inode called struct cdev_priv. It is important
to keep in mind that this "inode" is shared between all DEVFS
mountpoints, therefore it is protected by the global device mutex.
Link the cdev_priv's into a list, protected by the global device
mutex. Keep track of each cdev_priv's state with a flag bit and
of references from mountpoints with a dedicated usecount.
Reap the benefits of much improved kernel memory allocator and the
generally better defined device driver APIs to get rid of the tables
of pointers + serial numbers, their overflow tables, the atomics
to muck about in them and all the trouble that resulted in.
This makes RAM the only limit on how many devices we can have.
The cdev_priv is actually a super struct containing the normal cdev
as the "public" part, and therefore allocation and freeing has moved
to devfs_devs.c from kern_conf.c.
The overall responsibility is (to be) split such that kern/kern_conf.c
is the stuff that deals with drivers and struct cdev and fs/devfs
handles filesystems and struct cdev_priv and their private liason
exposed only in devfs_int.h.
Move the inode number from cdev to cdev_priv and allocate inode
numbers properly with unr. Local dirents in the mountpoints
(directories, symlinks) allocate inodes from the same pool to
guarantee against overlaps.
Various other fields are going to migrate from cdev to cdev_priv
in the future in order to hide them. A few fields may migrate
from devfs_dirent to cdev_priv as well.
Protect the DEVFS mountpoint with an sx lock instead of lockmgr,
this lock also protects the directory tree of the mountpoint.
Give each mountpoint a unique integer index, allocated with unr.
Use it into an array of devfs_dirent pointers in each cdev_priv.
Initially the array points to a single element also inside cdev_priv,
but as more devfs instances are mounted, the array is extended with
malloc(9) as necessary when the filesystem populates its directory
tree.
Retire the cdev alias lists, the cdev_priv now know about all the
relevant devfs_dirents (and their vnodes) and devfs_revoke() will
pick them up from there. We still spelunk into other mountpoints
and fondle their data without 100% good locking. It may make better
sense to vector the revoke event into the tty code and there do a
destroy_dev/make_dev on the tty's devices, but that's for further
study.
Lots of shuffling of stuff and churn of bits for no good reason[2].
XXX: There is still nothing preventing the dev_clone EVENTHANDLER
from being invoked at the same time in two devfs mountpoints. It
is not obvious what the best course of action is here.
XXX: comment out an if statement that lost its body, until I can
find out what should go there so it doesn't do damage in the meantime.
XXX: Leave in a few extra malloc types and KASSERTS to help track
down any remaining issues.
Much testing provided by: Kris
Much confusion caused by (races in): md(4)
[1] You are not supposed to understand anything past this point.
[2] This line should simplify life for the peanut gallery.
2005-09-19 19:56:48 +00:00
|
|
|
#define DEVFS_ROOTINO 2
|
2005-09-15 06:57:28 +00:00
|
|
|
|
Rewamp DEVFS internals pretty severely [1].
Give DEVFS a proper inode called struct cdev_priv. It is important
to keep in mind that this "inode" is shared between all DEVFS
mountpoints, therefore it is protected by the global device mutex.
Link the cdev_priv's into a list, protected by the global device
mutex. Keep track of each cdev_priv's state with a flag bit and
of references from mountpoints with a dedicated usecount.
Reap the benefits of much improved kernel memory allocator and the
generally better defined device driver APIs to get rid of the tables
of pointers + serial numbers, their overflow tables, the atomics
to muck about in them and all the trouble that resulted in.
This makes RAM the only limit on how many devices we can have.
The cdev_priv is actually a super struct containing the normal cdev
as the "public" part, and therefore allocation and freeing has moved
to devfs_devs.c from kern_conf.c.
The overall responsibility is (to be) split such that kern/kern_conf.c
is the stuff that deals with drivers and struct cdev and fs/devfs
handles filesystems and struct cdev_priv and their private liason
exposed only in devfs_int.h.
Move the inode number from cdev to cdev_priv and allocate inode
numbers properly with unr. Local dirents in the mountpoints
(directories, symlinks) allocate inodes from the same pool to
guarantee against overlaps.
Various other fields are going to migrate from cdev to cdev_priv
in the future in order to hide them. A few fields may migrate
from devfs_dirent to cdev_priv as well.
Protect the DEVFS mountpoint with an sx lock instead of lockmgr,
this lock also protects the directory tree of the mountpoint.
Give each mountpoint a unique integer index, allocated with unr.
Use it into an array of devfs_dirent pointers in each cdev_priv.
Initially the array points to a single element also inside cdev_priv,
but as more devfs instances are mounted, the array is extended with
malloc(9) as necessary when the filesystem populates its directory
tree.
Retire the cdev alias lists, the cdev_priv now know about all the
relevant devfs_dirents (and their vnodes) and devfs_revoke() will
pick them up from there. We still spelunk into other mountpoints
and fondle their data without 100% good locking. It may make better
sense to vector the revoke event into the tty code and there do a
destroy_dev/make_dev on the tty's devices, but that's for further
study.
Lots of shuffling of stuff and churn of bits for no good reason[2].
XXX: There is still nothing preventing the dev_clone EVENTHANDLER
from being invoked at the same time in two devfs mountpoints. It
is not obvious what the best course of action is here.
XXX: comment out an if statement that lost its body, until I can
find out what should go there so it doesn't do damage in the meantime.
XXX: Leave in a few extra malloc types and KASSERTS to help track
down any remaining issues.
Much testing provided by: Kris
Much confusion caused by (races in): md(4)
[1] You are not supposed to understand anything past this point.
[2] This line should simplify life for the peanut gallery.
2005-09-19 19:56:48 +00:00
|
|
|
extern unsigned devfs_rule_depth;
|
2000-08-24 15:36:55 +00:00
|
|
|
|
2000-08-20 21:34:39 +00:00
|
|
|
#define VFSTODEVFS(mp) ((struct devfs_mount *)((mp)->mnt_data))
|
|
|
|
|
|
2002-07-17 01:46:48 +00:00
|
|
|
void devfs_rules_apply(struct devfs_mount *dm, struct devfs_dirent *de);
|
2005-09-15 08:36:37 +00:00
|
|
|
int devfs_rules_ioctl(struct devfs_mount *dm, u_long cmd, caddr_t data, struct thread *td);
|
2002-07-17 01:46:48 +00:00
|
|
|
void devfs_rules_newmount(struct devfs_mount *dm, struct thread *td);
|
2001-09-12 08:38:13 +00:00
|
|
|
int devfs_allocv (struct devfs_dirent *de, struct mount *mp, struct vnode **vpp, struct thread *td);
|
2004-06-16 09:47:26 +00:00
|
|
|
struct cdev **devfs_itod (int inode);
|
2000-09-06 11:26:43 +00:00
|
|
|
struct devfs_dirent **devfs_itode (struct devfs_mount *dm, int inode);
|
Rewamp DEVFS internals pretty severely [1].
Give DEVFS a proper inode called struct cdev_priv. It is important
to keep in mind that this "inode" is shared between all DEVFS
mountpoints, therefore it is protected by the global device mutex.
Link the cdev_priv's into a list, protected by the global device
mutex. Keep track of each cdev_priv's state with a flag bit and
of references from mountpoints with a dedicated usecount.
Reap the benefits of much improved kernel memory allocator and the
generally better defined device driver APIs to get rid of the tables
of pointers + serial numbers, their overflow tables, the atomics
to muck about in them and all the trouble that resulted in.
This makes RAM the only limit on how many devices we can have.
The cdev_priv is actually a super struct containing the normal cdev
as the "public" part, and therefore allocation and freeing has moved
to devfs_devs.c from kern_conf.c.
The overall responsibility is (to be) split such that kern/kern_conf.c
is the stuff that deals with drivers and struct cdev and fs/devfs
handles filesystems and struct cdev_priv and their private liason
exposed only in devfs_int.h.
Move the inode number from cdev to cdev_priv and allocate inode
numbers properly with unr. Local dirents in the mountpoints
(directories, symlinks) allocate inodes from the same pool to
guarantee against overlaps.
Various other fields are going to migrate from cdev to cdev_priv
in the future in order to hide them. A few fields may migrate
from devfs_dirent to cdev_priv as well.
Protect the DEVFS mountpoint with an sx lock instead of lockmgr,
this lock also protects the directory tree of the mountpoint.
Give each mountpoint a unique integer index, allocated with unr.
Use it into an array of devfs_dirent pointers in each cdev_priv.
Initially the array points to a single element also inside cdev_priv,
but as more devfs instances are mounted, the array is extended with
malloc(9) as necessary when the filesystem populates its directory
tree.
Retire the cdev alias lists, the cdev_priv now know about all the
relevant devfs_dirents (and their vnodes) and devfs_revoke() will
pick them up from there. We still spelunk into other mountpoints
and fondle their data without 100% good locking. It may make better
sense to vector the revoke event into the tty code and there do a
destroy_dev/make_dev on the tty's devices, but that's for further
study.
Lots of shuffling of stuff and churn of bits for no good reason[2].
XXX: There is still nothing preventing the dev_clone EVENTHANDLER
from being invoked at the same time in two devfs mountpoints. It
is not obvious what the best course of action is here.
XXX: comment out an if statement that lost its body, until I can
find out what should go there so it doesn't do damage in the meantime.
XXX: Leave in a few extra malloc types and KASSERTS to help track
down any remaining issues.
Much testing provided by: Kris
Much confusion caused by (races in): md(4)
[1] You are not supposed to understand anything past this point.
[2] This line should simplify life for the peanut gallery.
2005-09-19 19:56:48 +00:00
|
|
|
void devfs_delete(struct devfs_mount *dm, struct devfs_dirent *de);
|
2005-09-15 10:28:19 +00:00
|
|
|
void devfs_populate (struct devfs_mount *dm);
|
Rewamp DEVFS internals pretty severely [1].
Give DEVFS a proper inode called struct cdev_priv. It is important
to keep in mind that this "inode" is shared between all DEVFS
mountpoints, therefore it is protected by the global device mutex.
Link the cdev_priv's into a list, protected by the global device
mutex. Keep track of each cdev_priv's state with a flag bit and
of references from mountpoints with a dedicated usecount.
Reap the benefits of much improved kernel memory allocator and the
generally better defined device driver APIs to get rid of the tables
of pointers + serial numbers, their overflow tables, the atomics
to muck about in them and all the trouble that resulted in.
This makes RAM the only limit on how many devices we can have.
The cdev_priv is actually a super struct containing the normal cdev
as the "public" part, and therefore allocation and freeing has moved
to devfs_devs.c from kern_conf.c.
The overall responsibility is (to be) split such that kern/kern_conf.c
is the stuff that deals with drivers and struct cdev and fs/devfs
handles filesystems and struct cdev_priv and their private liason
exposed only in devfs_int.h.
Move the inode number from cdev to cdev_priv and allocate inode
numbers properly with unr. Local dirents in the mountpoints
(directories, symlinks) allocate inodes from the same pool to
guarantee against overlaps.
Various other fields are going to migrate from cdev to cdev_priv
in the future in order to hide them. A few fields may migrate
from devfs_dirent to cdev_priv as well.
Protect the DEVFS mountpoint with an sx lock instead of lockmgr,
this lock also protects the directory tree of the mountpoint.
Give each mountpoint a unique integer index, allocated with unr.
Use it into an array of devfs_dirent pointers in each cdev_priv.
Initially the array points to a single element also inside cdev_priv,
but as more devfs instances are mounted, the array is extended with
malloc(9) as necessary when the filesystem populates its directory
tree.
Retire the cdev alias lists, the cdev_priv now know about all the
relevant devfs_dirents (and their vnodes) and devfs_revoke() will
pick them up from there. We still spelunk into other mountpoints
and fondle their data without 100% good locking. It may make better
sense to vector the revoke event into the tty code and there do a
destroy_dev/make_dev on the tty's devices, but that's for further
study.
Lots of shuffling of stuff and churn of bits for no good reason[2].
XXX: There is still nothing preventing the dev_clone EVENTHANDLER
from being invoked at the same time in two devfs mountpoints. It
is not obvious what the best course of action is here.
XXX: comment out an if statement that lost its body, until I can
find out what should go there so it doesn't do damage in the meantime.
XXX: Leave in a few extra malloc types and KASSERTS to help track
down any remaining issues.
Much testing provided by: Kris
Much confusion caused by (races in): md(4)
[1] You are not supposed to understand anything past this point.
[2] This line should simplify life for the peanut gallery.
2005-09-19 19:56:48 +00:00
|
|
|
void devfs_cleanup (struct devfs_mount *dm);
|
2000-09-06 11:26:43 +00:00
|
|
|
struct devfs_dirent *devfs_newdirent (char *name, int namelen);
|
Rewamp DEVFS internals pretty severely [1].
Give DEVFS a proper inode called struct cdev_priv. It is important
to keep in mind that this "inode" is shared between all DEVFS
mountpoints, therefore it is protected by the global device mutex.
Link the cdev_priv's into a list, protected by the global device
mutex. Keep track of each cdev_priv's state with a flag bit and
of references from mountpoints with a dedicated usecount.
Reap the benefits of much improved kernel memory allocator and the
generally better defined device driver APIs to get rid of the tables
of pointers + serial numbers, their overflow tables, the atomics
to muck about in them and all the trouble that resulted in.
This makes RAM the only limit on how many devices we can have.
The cdev_priv is actually a super struct containing the normal cdev
as the "public" part, and therefore allocation and freeing has moved
to devfs_devs.c from kern_conf.c.
The overall responsibility is (to be) split such that kern/kern_conf.c
is the stuff that deals with drivers and struct cdev and fs/devfs
handles filesystems and struct cdev_priv and their private liason
exposed only in devfs_int.h.
Move the inode number from cdev to cdev_priv and allocate inode
numbers properly with unr. Local dirents in the mountpoints
(directories, symlinks) allocate inodes from the same pool to
guarantee against overlaps.
Various other fields are going to migrate from cdev to cdev_priv
in the future in order to hide them. A few fields may migrate
from devfs_dirent to cdev_priv as well.
Protect the DEVFS mountpoint with an sx lock instead of lockmgr,
this lock also protects the directory tree of the mountpoint.
Give each mountpoint a unique integer index, allocated with unr.
Use it into an array of devfs_dirent pointers in each cdev_priv.
Initially the array points to a single element also inside cdev_priv,
but as more devfs instances are mounted, the array is extended with
malloc(9) as necessary when the filesystem populates its directory
tree.
Retire the cdev alias lists, the cdev_priv now know about all the
relevant devfs_dirents (and their vnodes) and devfs_revoke() will
pick them up from there. We still spelunk into other mountpoints
and fondle their data without 100% good locking. It may make better
sense to vector the revoke event into the tty code and there do a
destroy_dev/make_dev on the tty's devices, but that's for further
study.
Lots of shuffling of stuff and churn of bits for no good reason[2].
XXX: There is still nothing preventing the dev_clone EVENTHANDLER
from being invoked at the same time in two devfs mountpoints. It
is not obvious what the best course of action is here.
XXX: comment out an if statement that lost its body, until I can
find out what should go there so it doesn't do damage in the meantime.
XXX: Leave in a few extra malloc types and KASSERTS to help track
down any remaining issues.
Much testing provided by: Kris
Much confusion caused by (races in): md(4)
[1] You are not supposed to understand anything past this point.
[2] This line should simplify life for the peanut gallery.
2005-09-19 19:56:48 +00:00
|
|
|
struct devfs_dirent *devfs_vmkdir (struct devfs_mount *, char *name, int namelen, struct devfs_dirent *dotdot, u_int inode);
|
|
|
|
|
struct devfs_dirent *devfs_find (struct devfs_dirent *dd, const char *name, int namelen);
|
2000-09-06 11:26:43 +00:00
|
|
|
|
2000-08-20 21:34:39 +00:00
|
|
|
#endif /* _KERNEL */
|
2002-04-21 15:47:03 +00:00
|
|
|
|
|
|
|
|
#endif /* !_FS_DEVFS_DEVFS_H_ */
|
