Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Aug 2010 17:01:49 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Ed Schouten <ed@80386.nl>
Cc:        Ian FREISLICH <ianf@clue.co.za>, freebsd-current@freebsd.org
Subject:   Re: fusefs-kmod broken?
Message-ID:  <20100823140149.GG2396@deviant.kiev.zoral.com.ua>
In-Reply-To: <20100823134723.GC64651@hoeg.nl>
References:  <201008230826.49509.jhb@freebsd.org> <E1OmUBI-0000Oy-J5@clue.co.za> <E1OnWc7-0001Kv-47@clue.co.za> <20100823132551.GE2396@deviant.kiev.zoral.com.ua> <20100823133555.GA64651@hoeg.nl> <20100823134459.GF2396@deviant.kiev.zoral.com.ua> <20100823134723.GC64651@hoeg.nl>

next in thread | previous in thread | raw e-mail | index | archive | help

--7hK5U8dVDlZxii7z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Schouten wrote:
> * Kostik Belousov <kostikbel@gmail.com> wrote:
> > On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote:
> > > * Kostik Belousov <kostikbel@gmail.com> wrote:
> > > > Which most likely means that fusesfs filled its own struct fileops
> > > > without properly initializing fo_truncate member.
> > >=20
> > > It's a bit misleading that cdevs automatically patch the table, while
> > > the fileops don't. Maybe it would be a good idea to patch finit() to
> > I do not understand your first sentence. Would you please elaborate ?
>=20
> Say, you create a cdev, if you don't implement all ops, it will check
> for null pointers and return error codes accordingly. This doesn't
> happen for fileops, which is probably one of the reasons why people
> sometimes forget to implement them.
>=20
> Wouldn't it be better to prevent this form of footshooting by adding
> assertions? This will add some overhead for any file descriptor created,
> but a kernel with INVARIANTS isn't meant to be fast.
Thanks, I see it now.

The cdev interface definitely falls into the public kernel interface.
Having to fill all cdevsw methods for a random driver is too much
burden put on the several dozens maintainers.

On the other hand, file level is not much widely used by third-party
components, and even in-tree code implements only ten different file
types.

I would not object loudly if someone put such checks as proposed
under INVARIANTS, but also I do not see a real point in having them.
Might be slightly better to put the checks, again under INVARIANTS,
in the fo_XXX() wrappers.

--7hK5U8dVDlZxii7z
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)

iEYEARECAAYFAkxyf0wACgkQC3+MBN1Mb4gjkACfWQSnkIDLXKiZECPd0x38vUpv
IpwAnAqH9sGw8rGNp4eg4ud0SUBLgreK
=ftxV
-----END PGP SIGNATURE-----

--7hK5U8dVDlZxii7z--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100823140149.GG2396>