Commit Graph

11 Commits

Author SHA1 Message Date
Poul-Henning Kamp
d2bae332d6 Remove the absolute count g_access_abs() function since experience has
shown that it is not useful.

Rename the relative count g_access_rel() function to g_access(), only
the name has changed.

Change all g_access_rel() calls in our CVS tree to call g_access() instead.

Add an #ifndef BURN_BRIDGES #define of g_access_rel() for source
code compatibility.
2004-02-12 22:42:11 +00:00
David E. O'Brien
50b1faef38 Use __FBSDID().
Approved by:	phk
2003-06-11 06:49:16 +00:00
Poul-Henning Kamp
f075585f67 Remove the G_CLASS_INITIALIZER, we do not need it anymore. 2003-05-31 16:59:27 +00:00
Poul-Henning Kamp
7da144d91c Use g_slice_spoiled() instead of g_std_spoiled(). 2003-05-02 08:21:02 +00:00
Poul-Henning Kamp
c4da4e46b2 Back out all the stuff that didn't belong in the last commit. 2003-05-02 06:42:59 +00:00
Poul-Henning Kamp
e65ab0f83f Use g_slice_spoiled() rather than g_std_spoiled().
Remember to free the buffer we got from g_read_data().
2003-05-02 06:36:14 +00:00
Poul-Henning Kamp
3924ad705e Time has run from the "run GEOM in userland" harness, and the new regression
test is built to test GEOM as running in the kernel.

This commit is basically "unifdef -D_KERNEL" to remove the mainly #include
related code to support the userland-harness.
2003-04-13 09:02:06 +00:00
Poul-Henning Kamp
c138fec0b5 Premptively change initializations of struct g_class to use C99
sparse struct initializations before we extend the struct with
new OAM related member functions.
2003-03-24 19:30:15 +00:00
Gordon Tetlow
ddfa3cce05 Add some comments about the deficiencies of this module. I had hoped to get
around to addressing them some more, but Real Life (tm) has gotten in the
way.
2003-02-07 17:50:33 +00:00
Gordon Tetlow
6be2e1dd37 Correct a comment. GEOM modules do not create /dev entries. They create
providers.

Pointed out by:	phk
2003-02-03 17:21:43 +00:00
Gordon Tetlow
a6fff888c3 Add the GEOM module that makes volume labels useful. A kernel compiled with
this will cause volume labels to be exposed in /dev/vol/<volname>. Currently,
there is no conflict resolution if more than one FS has the same volume name.

Reviewed by:	phk
2003-02-03 17:14:29 +00:00