[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Manual pages



Hello!

Here are some manual pages (one is only updated) for the calls I
added some time ago to mint. I would like if they made it into
the mint documentation package. Wasnt it Julian, who wanted to
collect them?

Regards,
Ulrich

--
+---------------+----------------------------+-----------------------+
| Ulrich Kuehn  | Internet:                  | Life is uncertain --  |
| Cand.Math.Inf | kuehn@math.uni-muenster.de | eat the dessert first |
+---------------+----------------------------+-----------------------+

-----------------schnipp---------------------------
.TH Psetuid 2 "MiNT Programmer's Manual" "Version 1.11" "Aug. 21, 1994"
.SH NAME
Pseteuid, Psetegid \- change a process' effective user or group id
.SH SYNOPSIS
.nf
WORD Pseteuid(WORD uid);
WORD Psetegid(WORD gid);
.fi
.SH DESCRIPTION
.I Pseteuid
sets the effective user id of the current process to
.IR uid ,
which must be a number between 0 and 255 inclusive.
This function call will only succeed if the effective user id is 0
or if the real user id is 0, so a root process can change its 
effective user id to any value.
.I Pseteuid
returns
.IR euid ,
if the call is successful, and EACCDN if the process does not have
the authority to change its own effective user id (i.e. if its user
id is not 0 at the time of the call).
.PP
Similarly,
.I Psetegid
sets the effective group id of the current process to
.IR gid ,
which again must be between 0 and 255. The new group id
.I gid
is returned if successful, and EACCDN is returned if
permission to change groups is denied.
.SH "SEE ALSO"
.IR Pgetuid (2)
.SH BUGS
Security in MiNT is a joke; don't rely on these calls to actually protect
you from anything, it's more for informational purposes.


--------------------schnapp---------------------------
.TH Dcntl 2 "MiNT Programmer's Manual" "Version 1.11" "Dec. 12, 1991"
.SH NAME
Dcntl \- perform a file system specific operation on a file or directory
.SH SYNOPSIS
.nf
#include <filesys.h>

LONG Dcntl( WORD cmd, char *name, LONG arg);
.fi
.SH DESCRIPTION
.I Dcntl
performs a file system specific command, given by
.IR cmd ,
upon the file or directory specified by
.IR name .
The exact nature of the operation performed depends upon the file
system on which
.I name
resides. The interpretation of the third argument
.I arg
depends upon the specific command.
.PP
There are currently only two built-in file systems which support
.I Dcntl
operations: one is the device file system U:\\DEV, the other is the
unified file system U:\\. The device file system understands
the following commands:

.IP DEV_INSTALL
Installs a new device driver whose name is given by
.I name
(which must be the complete path and file name, e.g.
U:\\DEV\\FOO). The device may be accessed only through
GEMDOS file operations; the BIOS will not be aware of it.
.I arg
is a pointer to a device descriptor structure:
.nf

struct dev_descr {
 /* pointer to device driver structure */
	DEVDRV	*driver;
 /* placed in the "aux" field of file cookies */
	short	dinfo;
 /* either 0 or O_TTY */
	short	flags;
 /* if flags&O_TTY, this points to the tty structure associated
  * with the device
  */
	struct tty *tty;
 /* reserved for future expansion -- set to 0 */
	long	reserved[4];
};
.fi

If the attempt to install the device is successful,
.I Dcntl
will return a pointer to a structure with type "struct kerinfo"
that describes the kernel (see the documentation for loadable
file systems for more information on this structure). This
structure is in protected memory and can be accessed only
in supervisor mode. Moreover, the structure is read only;
attempts to write to it will produce unpredictable errors.
If there is not enough memory to install the new device,
a null pointer will be returned.
.IP DEV_NEWTTY
Installs a driver for a new BIOS terminal device whose name is
.I name
(this must be the full path name, e.g.
U:\\DEV\\BAR).
.I arg
is the BIOS device number of this device. Note that the BIOS
must have been told about the device already via the
.I Bconmap
system call or some similar mechanism; otherwise, any attempt
to access the file will result in an unknown device error
(EUNDEV). This command simply informs the kernel about a BIOS
device that already exists, unlike DEV_INSTALL which actually
creates a new device.

.IP DEV_NEWBIOS
Installs a driver for a new BIOS non-terminal device whose name is
.I name
(this must be the full path name, e.g.
U:\\DEV\\BAR).
.I arg
is the BIOS device number of this device. Note that the BIOS
must have been told about the device already via the
.I Bconmap
system call or some similar mechanism; otherwise, any attempt
to access the file will result in an unknown device error
(EUNDEV). Like DEV_NEWTTY, this command informs the kernel
of the existence of a BIOS device. The difference between
the two commands is that DEV_NEWTTY should be used for devices
which may be used as terminal devices (e.g. serial lines),
whereas DEV_NEWBIOS is useful for devices for which data must
be always transmitted "raw" (e.g. a SCSI tape device, or perhaps
a LAN device).

The following commands are only valid on the unified file system:

.IP FS_INSTALL
Installs a new file system. The name is not used here and can be anything
which is on the unified file system, e.g. U:\\FOO. The new file system
after a successive call only known to the system, but is not visible
to all processes. arg is a pointer to a file system descriptor structure:
.nf

struct fs_descr {
  /* pointer to file system structure */
  FILESYS *file_system;
  /* device number given by kernel on FS_MOUNT */
  short dev_no;
  /* several flags, unused so far */
	long flags;
  /* reserved for future use, set to 0 */
  long reserved[4];
};

.fi
If the attempt to install the file system is successful, Dcntl will 
return a pointer to a structure with type "struct kerinfo" that
describes the kernel (see documentation fol loadable file systems
for more information on this structure). This structure is in 
protected memory and can be accessed only in supervisor mode.
Moreover, it is read only; attempts to write to it will produce 
unpredictable errors. The call will fail if the file system is 
already installed. In this case a null pointer is returned.

.IP FS_MOUNT
Mount a file system to a directory whose name is given by name 
(which must be the complete path and file name, e.g. U:\\FOO_FS).
This file sytem can be used like any other with the GEMDOS file 
operations. arg is a pointer to a file system descriptor structure
(see above). On success, the call will place a unique device number
into the file system descriptor structure, which is used in the
file system's root() function to determine if it handles that device
(these devices are different from the BIOS devices in U:\\DEV).

The call will fail, if the file system was not installed with
FS_INSTALL, or if there is not enough memory left, or if the 
specified name does already exist. On success, the unique device
number is also returned as the return value.


.IP FS_UNMOUNT
Unmount a file system from a directory whose name is given by name
(which must again be the complete path and file name).
All open files on the file system (contained in the directory) are
closed, and the device number is no longer valid, so the file system
has ta make sure that further calls to the roo() function with
this device number will fail.
The call will fail if the file system was not mounted to name.
arg is a pointer to a file system descriptor structure (see above).

.IP FS_UNINSTALL
Remove a file system from the kernel's list of known file systems.
The file system must not be mounted any more for this call to succeed.
Further FS_MOUNT calls will fail, as if the file system never existed.


 
.SH RETURNS
The value returned depends on the specific operation requested and
the file system involved. Generally, a 0 or positive return value
should mean success, and a negative one failure. An exception is
the value returned by DEV_INSTALL and FS_INSTALL, which is either a pointer
to a kernel information structure, or null on failure.

.SH BUGS
If a process has installed a device or file system and exits before 
uninstalling it, the will be dangling pointers in the system, which
can lead to unpredictable results.

.SH "SEE ALSO"
.IR Bconmap (2),
.IR Fcntl (2)