headers
Maxim Zhuravlev | 1 Feb 2008 15:49
Picon
Favicon

Re: [RFC] Some new generic device features.

2008/1/31, Hans Petter Selasky <hselasky <at> c2i.net>:
> Hi,
>
> Some general comments:
>
> How does it handle mutexes?

By now mutexes are used by io subsystem:
All input/output requests (iors) and queues of iors are guarded by spin mutexes.
As for devices, their NewBus sided structures will be guarded by
(spin?) mutexes.

> Does it support non-giant enabled input drivers?

I don't really get what you mean. Did that answer about NewBus sided
structures  + paralleled/serialized ior processing clarify anything?

--
- Maxim Zhuravlev
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 1 comment |
headers
Poul-Henning Kamp | 2 Feb 2008 21:47
Picon
Favicon

adding general purpose mtx+cv to kthread


The select(2) system call has a dirty little secret data structure
(struct seltd) which it hangs off the kthread (->td_sel), amongst
the reasons for this is to avoid a mtx_init() and cv_init() and associated
destroy calls with each call to select(2).

I'm working on an enhancement to sendfile(2) that has the exact same
need for a mtx+cv combo and the question is how many other such
we have, once we get through the code.

Various solutions present themselves, from swallowing the overhead
for sendfile(2) since it's probably delta anyway over sharing selects
data structure (safe for the locks, since both syscalls are stateless)
to what seems most sensible to me:

Add a general purpose mtx+cv to struct kthread for use by syscalls
that need to keep track of things and sleep on stuff.

This wouldn't make the seltd structure go away, it contains other
stuff as well, it would just eliminate the mtx+cv combo from it.

Any comment or insights ?

--

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk <at> FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply | 1 comment |
headers
Julian Elischer | 3 Feb 2008 06:26

Re: adding general purpose mtx+cv to kthread

Poul-Henning Kamp wrote:
> The select(2) system call has a dirty little secret data structure
> (struct seltd) which it hangs off the kthread (->td_sel), amongst
> the reasons for this is to avoid a mtx_init() and cv_init() and associated
> destroy calls with each call to select(2).
> 
> I'm working on an enhancement to sendfile(2) that has the exact same
> need for a mtx+cv combo and the question is how many other such
> we have, once we get through the code.
> 
> Various solutions present themselves, from swallowing the overhead
> for sendfile(2) since it's probably delta anyway over sharing selects
> data structure (safe for the locks, since both syscalls are stateless)
> to what seems most sensible to me:
> 
> Add a general purpose mtx+cv to struct kthread for use by syscalls
> that need to keep track of things and sleep on stuff.
> 
> This wouldn't make the seltd structure go away, it contains other
> stuff as well, it would just eliminate the mtx+cv combo from it.
> 
> Any comment or insights ?
        [...]
	void *td_syscal_priv; /* valid for duration of syscall only */
        [...]

seems a reasonably useful thing

_______________________________________________
freebsd-arch <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Watson | 3 Feb 2008 10:33
Picon
Favicon

Re: [RFC] Some new generic device features.


On Fri, 1 Feb 2008, Maxim Zhuravlev wrote:

> 2008/1/31, Hans Petter Selasky <hselasky <at> c2i.net>:
>
>> Some general comments:
>>
>> How does it handle mutexes?
>
> By now mutexes are used by io subsystem: All input/output requests (iors) 
> and queues of iors are guarded by spin mutexes. As for devices, their NewBus 
> sided structures will be guarded by (spin?) mutexes.

Generic question: is it desirable/necessary to do this using [solely] spin 
mutexes?  They are more expensive than regular mutexes (since they also 
disable interrupts), and are not generally necessary unless code is running 
under the scheduler or in a fast interrupt context.  There are good reasons to 
write device driver code that runs in the fast interrupt context, but serious 
work (i.e., passing things up and down higher level stacks such as CAM, the 
network stack, ttys, etc) generally happens outside of that context.  If some 
of this necessarily runs in those sensitive contexts, is it the case that it 
mostly does?

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Marcus Clarke | 3 Feb 2008 20:03
Favicon

Re: HAL/freebsd architecture


On Tue, 2008-01-29 at 14:07 +0200, Andriy Gapon wrote:
> This is not a concrete suggestion and I can not volunteer to write any
> code yet (unfortunately).
> 
> Recently I played a little bit with DesktopBSD live CD and liked some
> add-on software provided there and some implementation approaches were
> quite interesting for me too.
> 
> Just in case, the tools can be found in sysutils/desktopbsd-tools and
> there is a FAQ page on using them in "plain" FreeBSD:
> http://desktopbsd.net/wiki/doku.php?id=doc:desktopbsd_tools_in_freebsd
> 
> This got me thinking: maybe we could also apply the same approach as
> used for dbsd-hwnotify to HAL/FreeBSD. I.e. hald could do initial
> querying of devices and then just wait for notification from devd about
> any changes.
> 
> This, of course, would require some changes to the base system, but I
> think that these would be useful for many more applications than just hald.
> 
> Some things that come to mind first: "forward" instruction to devd.conf
> to execute some action for all events in addition to any event-specific
> actions. This is so that we could preserve current devd functionality
> but also allow to delegate some decisions to other software.
> 
> I think that this way we could get a lot of current hald functionality
> for free, without the special probing/polling routines that have to
> written at present.
> But this would probably mean some additional changes in kernel-land. For
(Continue reading)

Permalink | Reply | 4 comments |
headers
Robert Watson | 3 Feb 2008 21:59
Picon
Favicon

8.0 network stack MPsafety goals (fwd)


Only a few days after predicted, this is a reminder that IFF_NEEDSGIANT 
network drivers are going to stop working in the forseeable future.  Please 
review the attached driver list, and if you depend on or care about a 
Giant-dependent device driver, take action to make sure it doesn't remain on 
the list in a month's time!

(As far as I'm aware, the list has not changed since my December posting.)

Robert N M Watson
Computer Laboratory
University of Cambridge

---------- Forwarded message ----------
Date: Mon, 24 Dec 2007 10:43:28 +0000 (GMT)
From: Robert Watson <rwatson <at> FreeBSD.org>
To: arch <at> FreeBSD.org
Subject: 8.0 network stack MPsafety goals

Dear all:

With the 7.0 release around the corner, many developers are starting to think 
about (and in quite a few cases, work on) their goals for 8.0.  One of our 
on-going kernel projects has been the elimination of the Giant lock, and that 
project has transformed into one of optimizating behavior on increasing numbers 
of processors.

In 7.0, despite the noteworth accomplishment of eliminating debug.mpsasfenet 
and conditional network stack Gian acquisition, we were unable to fully 
eliminate the IFF_NEEDSGIANT flag, which controls the conditional acquisition
(Continue reading)

Permalink | Reply | 0 comments |
headers
Attilio Rao | 7 Feb 2008 02:00
Picon
Favicon

[RFC] Remove NTFS kernel support

As exposed by several users, NTFS seems to be broken even before first
VFS commits happeing around the end of December. Those commits exposed
some problems about NTFS which are currently under investigation.
Ultimately, This filesystem is also unmaintained at the moment.

Speaking with jeff, we agreed on what can be a possible compromise:
remove the kernel support for NTFS and maybe take care of the FUSE
implementation.
What I now propose is a small survey which can shade a light on us
about what do you think about this idea and its implications:
- Do you use NTFS?
- Are you interested in maintaining it?
- Do you know a good reason to not use FUSE ntfs implementation? What
the kernel counter part adds?
- Do you think axing the kernel support a good idea?

Thanks,
Attilio

--

-- 
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 119 comments |
headers
Xin LI | 7 Feb 2008 02:31

Re: [RFC] Remove NTFS kernel support


Attilio Rao wrote:
> As exposed by several users, NTFS seems to be broken even before first
> VFS commits happeing around the end of December. Those commits exposed
> some problems about NTFS which are currently under investigation.
> Ultimately, This filesystem is also unmaintained at the moment.
> 
> Speaking with jeff, we agreed on what can be a possible compromise:
> remove the kernel support for NTFS and maybe take care of the FUSE
> implementation.
> What I now propose is a small survey which can shade a light on us
> about what do you think about this idea and its implications:
> - Do you use NTFS?

I use it occasionally when I need to copy files from the Windows partition.

> - Are you interested in maintaining it?

No.

> - Do you know a good reason to not use FUSE ntfs implementation? What
> the kernel counter part adds?

No, the only reason come to mind is that one don't need to install
separately, and thus might be good if you run -CURRENT.

> - Do you think axing the kernel support a good idea?

If nobody would maintain it, as long as the FUSE NTFS implementation is
usable I think it's a good idea to axe it in 8.0.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ganbold | 7 Feb 2008 02:46

Re: [RFC] Remove NTFS kernel support

Attilio Rao wrote:
> As exposed by several users, NTFS seems to be broken even before first
> VFS commits happeing around the end of December. Those commits exposed
> some problems about NTFS which are currently under investigation.
> Ultimately, This filesystem is also unmaintained at the moment.
>
> Speaking with jeff, we agreed on what can be a possible compromise:
> remove the kernel support for NTFS and maybe take care of the FUSE
> implementation.
> What I now propose is a small survey which can shade a light on us
> about what do you think about this idea and its implications:
> - Do you use NTFS?
>   

Yes, I have external NTFS USB hard drive and from time to time I need to 
copy
some files, delete etc.

> - Are you interested in maintaining it?
> - Do you know a good reason to not use FUSE ntfs implementation?

FUSE implementation allows to write to NTFS partition, so it is really 
useful.
However either fusefs-ntfs related stuff or kernel itself seems like 
buggy, I'm having fatal trap/crash when I try to mount NTFS
partition in FreeBSD-7.0-PRERELEASE.

>  What
> the kernel counter part adds?
> - Do you think axing the kernel support a good idea?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Emmerton | 7 Feb 2008 04:10
Picon
Favicon

Re: [RFC] Remove NTFS kernel support

> Speaking with jeff, we agreed on what can be a possible compromise:
> remove the kernel support for NTFS and maybe take care of the FUSE
> implementation.
> What I now propose is a small survey which can shade a light on us
> about what do you think about this idea and its implications:
> - Do you use NTFS?

Sometimes.

> - Are you interested in maintaining it?

Nope.

> - Do you know a good reason to not use FUSE ntfs implementation? What
> the kernel counter part adds?

FUSE would be fine by me.  I didn't realize FUSE was available on FreeBSD --  
in the past I typically booted with a Knoppix livecd and then tar over 
netcat to get files back to my BSD machines.  I'll use FUSE on FreeBSD from 
now on.

> - Do you think axing the kernel support a good idea?

Yep.

--
Matt Emmerton 

_______________________________________________
freebsd-fs <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply | 0 comments |

Gmane