1
0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-04 09:09:56 +00:00
freebsd/lib/libstand/open.c

160 lines
4.6 KiB
C
Raw Normal View History

/* $NetBSD: open.c,v 1.16 1997/01/28 09:41:03 pk Exp $ */
/*-
* Copyright (c) 1993
* The Regents of the University of California. All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* The Mach Operating System project at Carnegie-Mellon University.
*
* 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. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 4. 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.
*
* @(#)open.c 8.1 (Berkeley) 6/11/93
*
*
* Copyright (c) 1989, 1990, 1991 Carnegie Mellon University
* All Rights Reserved.
*
* Author: Alessandro Forin
*
* Permission to use, copy, modify and distribute this software and its
* documentation is hereby granted, provided that both the copyright
* notice and this permission notice appear in all copies of the
* software, derivative works or modified versions, and any portions
* thereof, and that both notices appear in supporting documentation.
*
* CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS IS"
* CONDITION. CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF ANY KIND FOR
* ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS SOFTWARE.
*
* Carnegie Mellon requests users of this software to return to
*
* Software Distribution Coordinator or Software.Distribution@CS.CMU.EDU
* School of Computer Science
* Carnegie Mellon University
* Pittsburgh PA 15213-3890
*
* any improvements or extensions that they make and grant Carnegie the
* rights to redistribute these changes.
*/
2001-09-30 22:28:01 +00:00
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include "stand.h"
Provide a means for loaders to control which file system to use. This to counteract the default behaviour of always trying each and every file system until one succeeds, or the open fails. The problem with the loader is that we've implemented features based on this behavior. The handling of compressed files is a good example of this. However, it is in general highly undesirable to not have a one-time probe (or taste in the geom lingo), followed by something similar to a mount whenever we (first) read from a device. Everytime we go to the same device, we can reasonably assume it (still) has the same file system. For file systems that need to do far more that a trivial read of a super block, not having something similar to a mount operation is disastrous from a performance (and thus usability) perspective. But, again, since we've implemented features based on this stateless approach, things can get complicated quickly if and when we want to change this. And yet, we sometimes do need stateful behaviour. For this reason, this change simply introduces exclusive_file_system. When set to the fsops of the file system to use, the open call will only try this file system. Setting it to NULL restores the default behaviour. It's a low-cost (low-brow?) approach to provide enough control without re-implementing the guts of the loader. A good example of when this is useful is when we're trying to load files out of a container (say, a software packaga) that itself lives on a file system or is fetched over the network. While opening the container can be done in the normal stateless manner, once it is opened, subsequent opens should only consider the container. Obtained from: Juniper Networks, Inc.
2014-07-30 16:08:16 +00:00
struct fs_ops *exclusive_file_system;
struct open_file files[SOPEN_MAX];
static int
o_gethandle(void)
{
int fd;
for (fd = 0; fd < SOPEN_MAX; fd++)
if (files[fd].f_flags == 0)
return(fd);
return(-1);
}
static void
o_rainit(struct open_file *f)
{
f->f_rabuf = malloc(SOPEN_RASIZE);
f->f_ralen = 0;
f->f_raoffset = 0;
}
int
open(const char *fname, int mode)
{
Provide a means for loaders to control which file system to use. This to counteract the default behaviour of always trying each and every file system until one succeeds, or the open fails. The problem with the loader is that we've implemented features based on this behavior. The handling of compressed files is a good example of this. However, it is in general highly undesirable to not have a one-time probe (or taste in the geom lingo), followed by something similar to a mount whenever we (first) read from a device. Everytime we go to the same device, we can reasonably assume it (still) has the same file system. For file systems that need to do far more that a trivial read of a super block, not having something similar to a mount operation is disastrous from a performance (and thus usability) perspective. But, again, since we've implemented features based on this stateless approach, things can get complicated quickly if and when we want to change this. And yet, we sometimes do need stateful behaviour. For this reason, this change simply introduces exclusive_file_system. When set to the fsops of the file system to use, the open call will only try this file system. Setting it to NULL restores the default behaviour. It's a low-cost (low-brow?) approach to provide enough control without re-implementing the guts of the loader. A good example of when this is useful is when we're trying to load files out of a container (say, a software packaga) that itself lives on a file system or is fetched over the network. While opening the container can be done in the normal stateless manner, once it is opened, subsequent opens should only consider the container. Obtained from: Juniper Networks, Inc.
2014-07-30 16:08:16 +00:00
struct fs_ops *fs;
struct open_file *f;
int fd, i, error, besterror;
const char *file;
if ((fd = o_gethandle()) == -1) {
errno = EMFILE;
return(-1);
}
f = &files[fd];
f->f_flags = mode + 1;
f->f_dev = (struct devsw *)0;
f->f_ops = (struct fs_ops *)0;
f->f_offset = 0;
f->f_devdata = NULL;
file = (char *)0;
Provide a means for loaders to control which file system to use. This to counteract the default behaviour of always trying each and every file system until one succeeds, or the open fails. The problem with the loader is that we've implemented features based on this behavior. The handling of compressed files is a good example of this. However, it is in general highly undesirable to not have a one-time probe (or taste in the geom lingo), followed by something similar to a mount whenever we (first) read from a device. Everytime we go to the same device, we can reasonably assume it (still) has the same file system. For file systems that need to do far more that a trivial read of a super block, not having something similar to a mount operation is disastrous from a performance (and thus usability) perspective. But, again, since we've implemented features based on this stateless approach, things can get complicated quickly if and when we want to change this. And yet, we sometimes do need stateful behaviour. For this reason, this change simply introduces exclusive_file_system. When set to the fsops of the file system to use, the open call will only try this file system. Setting it to NULL restores the default behaviour. It's a low-cost (low-brow?) approach to provide enough control without re-implementing the guts of the loader. A good example of when this is useful is when we're trying to load files out of a container (say, a software packaga) that itself lives on a file system or is fetched over the network. While opening the container can be done in the normal stateless manner, once it is opened, subsequent opens should only consider the container. Obtained from: Juniper Networks, Inc.
2014-07-30 16:08:16 +00:00
if (exclusive_file_system != NULL) {
fs = exclusive_file_system;
error = (fs->fo_open)(fname, f);
if (error == 0)
goto ok;
goto err;
Provide a means for loaders to control which file system to use. This to counteract the default behaviour of always trying each and every file system until one succeeds, or the open fails. The problem with the loader is that we've implemented features based on this behavior. The handling of compressed files is a good example of this. However, it is in general highly undesirable to not have a one-time probe (or taste in the geom lingo), followed by something similar to a mount whenever we (first) read from a device. Everytime we go to the same device, we can reasonably assume it (still) has the same file system. For file systems that need to do far more that a trivial read of a super block, not having something similar to a mount operation is disastrous from a performance (and thus usability) perspective. But, again, since we've implemented features based on this stateless approach, things can get complicated quickly if and when we want to change this. And yet, we sometimes do need stateful behaviour. For this reason, this change simply introduces exclusive_file_system. When set to the fsops of the file system to use, the open call will only try this file system. Setting it to NULL restores the default behaviour. It's a low-cost (low-brow?) approach to provide enough control without re-implementing the guts of the loader. A good example of when this is useful is when we're trying to load files out of a container (say, a software packaga) that itself lives on a file system or is fetched over the network. While opening the container can be done in the normal stateless manner, once it is opened, subsequent opens should only consider the container. Obtained from: Juniper Networks, Inc.
2014-07-30 16:08:16 +00:00
}
error = devopen(f, fname, &file);
if (error ||
(((f->f_flags & F_NODEV) == 0) && f->f_dev == (struct devsw *)0))
goto err;
/* see if we opened a raw device; otherwise, 'file' is the file name. */
if (file == (char *)0 || *file == '\0') {
f->f_flags |= F_RAW;
f->f_rabuf = NULL;
return (fd);
}
/* pass file name to the different filesystem open routines */
besterror = ENOENT;
for (i = 0; file_system[i] != NULL; i++) {
Provide a means for loaders to control which file system to use. This to counteract the default behaviour of always trying each and every file system until one succeeds, or the open fails. The problem with the loader is that we've implemented features based on this behavior. The handling of compressed files is a good example of this. However, it is in general highly undesirable to not have a one-time probe (or taste in the geom lingo), followed by something similar to a mount whenever we (first) read from a device. Everytime we go to the same device, we can reasonably assume it (still) has the same file system. For file systems that need to do far more that a trivial read of a super block, not having something similar to a mount operation is disastrous from a performance (and thus usability) perspective. But, again, since we've implemented features based on this stateless approach, things can get complicated quickly if and when we want to change this. And yet, we sometimes do need stateful behaviour. For this reason, this change simply introduces exclusive_file_system. When set to the fsops of the file system to use, the open call will only try this file system. Setting it to NULL restores the default behaviour. It's a low-cost (low-brow?) approach to provide enough control without re-implementing the guts of the loader. A good example of when this is useful is when we're trying to load files out of a container (say, a software packaga) that itself lives on a file system or is fetched over the network. While opening the container can be done in the normal stateless manner, once it is opened, subsequent opens should only consider the container. Obtained from: Juniper Networks, Inc.
2014-07-30 16:08:16 +00:00
fs = file_system[i];
error = (fs->fo_open)(file, f);
if (error == 0)
goto ok;
if (error != EINVAL)
besterror = error;
}
error = besterror;
Provide a means for loaders to control which file system to use. This to counteract the default behaviour of always trying each and every file system until one succeeds, or the open fails. The problem with the loader is that we've implemented features based on this behavior. The handling of compressed files is a good example of this. However, it is in general highly undesirable to not have a one-time probe (or taste in the geom lingo), followed by something similar to a mount whenever we (first) read from a device. Everytime we go to the same device, we can reasonably assume it (still) has the same file system. For file systems that need to do far more that a trivial read of a super block, not having something similar to a mount operation is disastrous from a performance (and thus usability) perspective. But, again, since we've implemented features based on this stateless approach, things can get complicated quickly if and when we want to change this. And yet, we sometimes do need stateful behaviour. For this reason, this change simply introduces exclusive_file_system. When set to the fsops of the file system to use, the open call will only try this file system. Setting it to NULL restores the default behaviour. It's a low-cost (low-brow?) approach to provide enough control without re-implementing the guts of the loader. A good example of when this is useful is when we're trying to load files out of a container (say, a software packaga) that itself lives on a file system or is fetched over the network. While opening the container can be done in the normal stateless manner, once it is opened, subsequent opens should only consider the container. Obtained from: Juniper Networks, Inc.
2014-07-30 16:08:16 +00:00
fail:
if ((f->f_flags & F_NODEV) == 0 && f->f_dev != NULL)
f->f_dev->dv_close(f);
if (error)
devclose(f);
err:
f->f_flags = 0;
errno = error;
return (-1);
Provide a means for loaders to control which file system to use. This to counteract the default behaviour of always trying each and every file system until one succeeds, or the open fails. The problem with the loader is that we've implemented features based on this behavior. The handling of compressed files is a good example of this. However, it is in general highly undesirable to not have a one-time probe (or taste in the geom lingo), followed by something similar to a mount whenever we (first) read from a device. Everytime we go to the same device, we can reasonably assume it (still) has the same file system. For file systems that need to do far more that a trivial read of a super block, not having something similar to a mount operation is disastrous from a performance (and thus usability) perspective. But, again, since we've implemented features based on this stateless approach, things can get complicated quickly if and when we want to change this. And yet, we sometimes do need stateful behaviour. For this reason, this change simply introduces exclusive_file_system. When set to the fsops of the file system to use, the open call will only try this file system. Setting it to NULL restores the default behaviour. It's a low-cost (low-brow?) approach to provide enough control without re-implementing the guts of the loader. A good example of when this is useful is when we're trying to load files out of a container (say, a software packaga) that itself lives on a file system or is fetched over the network. While opening the container can be done in the normal stateless manner, once it is opened, subsequent opens should only consider the container. Obtained from: Juniper Networks, Inc.
2014-07-30 16:08:16 +00:00
ok:
f->f_ops = fs;
o_rainit(f);
return (fd);
}