DragonFly BSD

CVS log for src/sys/vfs/isofs/cd9660/cd9660_node.h

[BACK] Up to [DragonFly] / src / sys / vfs / isofs / cd9660

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

Revision 1.10: download - view: text, markup, annotated - select for diffs
Sun Sep 10 01:26:40 2006 UTC (8 years, 10 months ago) by dillon
Branches: MAIN
CVS tags: HEAD, DragonFly_RELEASE_2_0_Slip, DragonFly_RELEASE_2_0, DragonFly_RELEASE_1_8_Slip, DragonFly_RELEASE_1_8, DragonFly_RELEASE_1_12_Slip, DragonFly_RELEASE_1_12, DragonFly_RELEASE_1_10_Slip, DragonFly_RELEASE_1_10, DragonFly_Preview
Diff to: previous 1.9: preferred, colored
Changes since revision 1.9: +2 -2 lines
Change the kernel dev_t, representing a pointer to a specinfo structure,
to cdev_t.  Change struct specinfo to struct cdev.  The name 'cdev' was taken
from FreeBSD.  Remove the dev_t shim for the kernel.

This commit generally removes the overloading of 'dev_t' between userland and
the kernel.

Also fix a bug in libkvm where a kernel dev_t (now cdev_t) was not being
properly converted to a userland dev_t.

Revision 1.9: download - view: text, markup, annotated - select for diffs
Sat Apr 1 21:55:13 2006 UTC (9 years, 3 months ago) by dillon
Branches: MAIN
CVS tags: DragonFly_RELEASE_1_6_Slip, DragonFly_RELEASE_1_6
Diff to: previous 1.8: preferred, colored
Changes since revision 1.8: +1 -0 lines
Clone cd9660_blkatoff() into a new procedure, cd9660_devblkatoff(), which
returns a devvp-relative buffer rather then the vp-relative buffer.  This
allows us to access meta-data relative to a vnode without having to
instantiate a VM object for that vnode.  The new function is used for
all directory scans and (negative offset) meta-data access.

This fixes a panic due to recent buffer cache commits that formalized
the requirements for using the buffer cache.

Also, prior to this change, the CD9660 filesystem was using B_MALLOC buffers
for a great deal of meta-data access that could very easily have been backed
by the device vnode's VM object instead.  B_MALLOC buffers have severe
caching limitations.  This commit fixes all of that as well.

Revision download - view: text, markup, annotated - select for diffs
Thu Mar 2 17:11:22 2006 UTC (9 years, 4 months ago) by dillon
Branches: DragonFly_RELEASE_1_4
CVS tags: DragonFly_RELEASE_1_4_Slip
Diff to: previous 1.7: preferred, colored; next MAIN 1.8: preferred, colored
Changes since revision 1.7: +4 -4 lines
MFC 1.8 - Fix file sizes > 2GB on isofs

Revision 1.8: download - view: text, markup, annotated - select for diffs
Mon Feb 27 02:50:48 2006 UTC (9 years, 5 months ago) by corecode
Branches: MAIN
Diff to: previous 1.7: preferred, colored
Changes since revision 1.7: +4 -4 lines
Fix file sizes > 2GB on isofs.  This has already been fixed in the other BSDs.

Submitted-by: Csaba Henk

Revision 1.7: download - view: text, markup, annotated - select for diffs
Wed Sep 14 01:13:37 2005 UTC (9 years, 10 months ago) by dillon
Branches: MAIN
Branch point for: DragonFly_RELEASE_1_4
Diff to: previous 1.6: preferred, colored
Changes since revision 1.6: +2 -2 lines
Rename all the functions and structures for the old VOP namespace API
functions from vop_* to vop_old_*.  e.g. vop_lookup -> vop_old_lookup.
This will make it easier to identify areas containing old VOP API code.

Remove vop_old_*_ap() functions, they are not used (and not allowed to be
used).  The old API is only allowed at the leaf of a VFS stack.

Revision 1.6: download - view: text, markup, annotated - select for diffs
Fri Nov 12 00:09:34 2004 UTC (10 years, 8 months ago) by dillon
Branches: MAIN
CVS tags: DragonFly_Stable, DragonFly_RELEASE_1_2_Slip, DragonFly_RELEASE_1_2
Diff to: previous 1.5: preferred, colored
Changes since revision 1.5: +2 -2 lines
VFS messaging/interfacing work stage 9/99: VFS 'NEW' API WORK.

NOTE: unionfs and nullfs are temporarily broken by this commit.

* Remove the old namecache API.  Remove vfs_cache_lookup(), cache_lookup(),
  cache_enter(), namei() and lookup() are all gone.  VOP_LOOKUP() and
  VOP_CACHEDLOOKUP() have been collapsed into a single non-caching

* Complete the new VFS CACHE (namecache) API.  The new API is able to
  supply topological guarentees and is able to reserve namespaces,
  including negative cache spaces (whether the target name exists or not),
  which the new API uses to reserve namespace for things like NRENAME
  and NCREATE (and others).

* Complete the new namecache API.  VOP_NRESOLVE, NLOOKUPDOTDOT, NCREATE,
  These new calls take (typicaly locked) namecache pointers rather then
  combinations of directory vnodes, file vnodes, and name components.  The
  new calls are *MUCH* simpler in concept and implementation.  For example,
  VOP_RENAME() has 8 arguments while VOP_NRENAME() has only 3 arguments.

  The new namecache API uses the namecache to lock namespaces without having
  to lock the underlying vnodes.  For example, this allows the kernel
  to reserve the target name of a create function trivially.  Namecache
  records are maintained BY THE KERNEL for both positive and negative hits.

  Generally speaking, the kernel layer is now responsible for resolving
  path elements.  NRESOLVE is called when an unresolved namecache record
  needs to be resolved.  Unlike the old VOP_LOOKUP, NRESOLVE is simply
  responsible for associating a vnode to a namecache record (positive hit)
  or telling the system that it's a negative hit, and not responsible for
  handling symlinks or other special cases or doing any of the other
  path lookup work, much unlike the old VOP_LOOKUP.

  It should be particularly noted that the new namecache topology does not
  allow disconnected namecache records.  In rare cases where a vnode must
  be converted to a namecache pointer for new API operation via a file handle
  (i.e. NFS), the cache_fromdvp() function is provided and a new API VOP,
  VOP_NLOOKUPDOTDOT() is provided to allow the namecache to resolve the
  topology leading up to the requested vnode.  These and other topological
  guarentees greatly reduce the complexity of the new namecache API.

  The new namei() is called nlookup().  This function uses a combination
  of cache_n*() calls, VOP_NRESOLVE(), and standard VOP calls resolve the
  supplied path, deal with symlinks, and so forth, in a nice small compact
  compartmentalized procedure.

* The old VFS code is no longer responsible for maintaining namecache records,
  a function which was mostly adhoc cache_purge()s occuring before the VFS
  actually knows whether an operation will succeed or not.

  The new VFS code is typically responsible for adjusting the state of
  locked namecache records passed into it.  For example, if NCREATE succeeds
  it must call cache_setvp() to associate the passed namecache record with
  the vnode representing the successfully created file.  The new requirements
  are much less complex then the old requirements.

* Most VFSs still implement the old API calls, albeit somewhat modified
  and in particular the VOP_LOOKUP function is now *MUCH* simpler.  However,
  the kernel now uses the new API calls almost exclusively and relies on
  compatibility code installed in the default ops (vop_compat_*()) to
  convert the new calls to the old calls.

* All kernel system calls and related support functions which used to do
  complex and confusing namei() operations now do far less complex and
  far less confusing nlookup() operations.

* SPECOPS shortcutting has been implemented.  User reads and writes now go
  directly to supporting functions which talk to the device via fileops
  rather then having to be routed through VOP_READ or VOP_WRITE, saving
  significant overhead.  Note, however, that these only really effect
  /dev/null and /dev/zero.

  Implementing this was fairly easy, we now simply pass an optional
  struct file pointer to VOP_OPEN() and let spec_open() handle the

SPECIAL NOTES: It should be noted that we must still lock a directory vnode
LK_EXCLUSIVE before issuing a VOP_LOOKUP(), even for simple lookups, because
a number of VFS's (including UFS) store active directory scanning information
in the directory vnode.  The legacy NAMEI_LOOKUP cases can be changed to
use LK_SHARED once these VFS cases are fixed.  In particular, we are now
organized well enough to actually be able to do record locking within a
directory for handling NCREATE, NDELETE, and NRENAME situations, but it hasn't
been done yet.

Many thanks to all of the testers and in particular David Rhodus for
finding a large number of panics and other issues.

Revision 1.5: download - view: text, markup, annotated - select for diffs
Sat Aug 28 19:02:15 2004 UTC (10 years, 11 months ago) by dillon
Branches: MAIN
CVS tags: DragonFly_Snap29Sep2004, DragonFly_Snap13Sep2004
Diff to: previous 1.4: preferred, colored
Changes since revision 1.4: +2 -3 lines
VFS messaging/interfacing work stage 4/99.  This stage goes a long ways
towards allowing us to move the vnode locking into a kernel layer.  It
gets rid of a lot of cruft from FreeBSD-4.  FreeBSD-5 has done some of this
stuff too (such as changing the default locking to stdlock from nolock),
but DragonFly is going further.

* Consolidate vnode locks into the vnode structure, add an embedded v_lock,
  and getting rid of both v_vnlock and v_data based head-of-structure locks.

* Change the default vops to use a standard vnode lock rather then a fake

* Get rid of vop_nolock() and friends, we no longer support non-locking

* Get rid of vop_sharedlock(), we no longer support non standard shared-only
  locks (only NFS was using it and the mount-crossing lookup code should
  now prevent races to root from dead NFS volumes).

* Integrate lock initialization into getnewvnode().  We do not yet
  incorporate automatically locking into getnewvnode().  getnewvnode()
  now has two additional arguments, lktimeout and lkflags, for lock
  structure initialization.

* Change the sync vnode lock from nolock to stdlock.  This may require more
  tuning down the line.  Fix various sync_inactive() to properly unlock
  the lock as per the VOP API.

* Properly flag the 'rename' vop operation regarding required tdvp and tvp
  unlocks (the flags are only used by nullfs).

* Get rid of all inode-embedded vnode locks

* Remove manual lockinit and use new getnewvnode() args instead.
  Lock the vnode prior to doing anything that might block in
  order to avoid synclist access before the vnode has been properly

* Generally change inode hash insertion to also check
  for a hash collision and return failure if it occurs,
  rather then doing (often non-atomic) relookups and
  other checks.  These sorts of collisions can occur
  if a vnode is being destroyed at the same time a new
  vnode is being created from an inode.  A new vnode is
  not generally accessible, except by the sync code (from
  the mountlist) until it's underlying inode has been hashed
  so dealing with a hash collision should be as simple as
  throwing away the vnode with a vput().

* Do not initialize a new vnode's v_data until after
  the associated inode has been successfully added to
  the hash, and make the xxx_inactive() and xxx_reclaim()
  code friendly towards vnodes with a NULL v_data.

* NFS now uses standard locks rather then shared-only locks.

* PROCFS now uses standard locks rather then non-locks, and PROCFS's
  lookup code now understands VOP lookup semantics.  PROCFS now uses
  a real hash table for its node search rather then a single singly-linked
  list (which should better scale to systems with thousands of processes).

* NULLFS should now properly handle lookup() and rename() locks.  NULLFS's
  node handling code has been rewritten.  NULLFS's bypass code now understands
  vnode unlocks (rename case).

* UFS no longer needs the ffs_inode_hash_lock hacks.  It now uses the new
  collision-on-hash-add methodology.   This will speed up UFS when operating
  on lots of small files (reported by David Rhodus).

Revision 1.4: download - view: text, markup, annotated - select for diffs
Mon May 3 16:06:26 2004 UTC (11 years, 2 months ago) by joerg
Branches: MAIN
CVS tags: DragonFly_1_0_REL, DragonFly_1_0_RC1, DragonFly_1_0A_REL
Diff to: previous 1.3: preferred, colored
Changes since revision 1.3: +3 -1 lines
POSIX lock resource limit part 3/4

This splits "struct lockf" into the general book-keeping of ranges and
blocked request and the "struct lockf_range" which constists of the data
for a specific range. Adjust the interface of lf_advlock to remove one
level of pointer indirection and embedded "struct lockf" directly in the
inodes. Don't mess with wait channels any more.

Change the algorithm for determing locks to a more direct approach, which
both simplifies the lock acquisition and proper book-keeping of the number
of ranges currently used. The later is necessary to prevent local resource

The code is not fully malloc block-safe, but as good or bad as
the old code.

Add the kernel part of the posixlocks rlimit. This is the maximum number of
POSIX lock ranges any user can acquire. These numbers are tracked for each
user and process and checked at lock/unlock time. If a process changes uid,
its locks are transfered to the new uid which can effectivly boost that
number above the limit.

This is based on the patch set from Devon H. O'Dell <dodell@sitetronics.com>
for the general infrastructure with some adjustment to better integrate with
the new lockf code.

Revision 1.3: download - view: text, markup, annotated - select for diffs
Wed Aug 20 09:56:32 2003 UTC (11 years, 11 months ago) by rob
Branches: MAIN
Diff to: previous 1.2: preferred, colored
Changes since revision 1.2: +15 -15 lines
__P()!=wanted, remove old style prototypes from the vfs subtree

Revision 1.2: download - view: text, markup, annotated - select for diffs
Tue Jun 17 04:28:41 2003 UTC (12 years, 1 month ago) by dillon
Branches: MAIN
CVS tags: PRE_MP
Diff to: previous 1.1: preferred, colored
Changes since revision 1.1: +1 -0 lines
Add the DragonFly cvs id and perform general cleanups on cvs/rcs/sccs ids.  Most
ids have been removed from !lint sections and moved into comment sections.

Revision 1.1: download - view: text, markup, annotated - select for diffs
Tue Jun 17 02:54:59 2003 UTC (12 years, 1 month ago) by dillon
Branches: MAIN
import from FreeBSD RELENG_4 1.20

Diff request

This form allows you to request diffs between any two revisions of a file. You may select a symbolic revision name using the selection box or you may type in a numeric name using the type-in text box.

Log view options