On Thu, Dec 17, 2020 at 9:33 AM Ian Lepore wrote:
> On Thu, 2020-12-17 at 18:22 +0200, Konstantin Belousov wrote:
> > On Thu, Dec 17, 2020 at 01:01:01PM +, Jessica Clarke wrote:
> > > On 17 Dec 2020, at 12:53, Konstantin Belousov
> > > wrote:
> > > >
> > > > On Thu, Dec 17, 2020 at 12:41:47P
This doesn't answer all of your questions but one important thing to
point out is that Mateusz is in communication with the OpenZFS and iX
folks to coordinate these changes and avoid expected merge conflicts.
The idealized workflow is that a change goes into OZFS first, but as
long as folks are in
On Fri, Sep 4, 2020 at 10:30 PM Warner Losh wrote:
>
>
>
> On Fri, Sep 4, 2020, 11:24 PM Kevin Bowling wrote:
>>
>> It's happening right now, and a few times a year at minimum from my
>> memory.
>
>
> Can I get a pointer?
>From recent lossy memor
Fri, Sep 4, 2020 at 8:48 PM Warner Losh wrote:
>
>
>
> On Fri, Sep 4, 2020, 9:11 PM Kevin Bowling wrote:
>>
>> I disagree that the problem is intractable. It's just a decision and
>> it has a one time cost with long term benefits like paying off a high
>> i
I disagree that the problem is intractable. It's just a decision and
it has a one time cost with long term benefits like paying off a high
interest loan. The intractability opinion seemed justifiable for a
long time but it's been proven false by other communities,
particularly Go and Rust and the
Out of curiosity what is panda?
On Sat, Jun 6, 2020 at 11:20 AM Michael Tuexen wrote:
>
> Author: tuexen
> Date: Sat Jun 6 18:20:09 2020
> New Revision: 361872
> URL: https://svnweb.freebsd.org/changeset/base/361872
>
> Log:
> Non-functional changes due to cleanup (upstream removing of Panda s
Were there any major changes you can summarize from the P9BSD
integration, and any TODO list (perhaps wiki for this question)?
On Sun, May 10, 2020 at 7:33 PM Justin Hibbits wrote:
>
> Author: jhibbits
> Date: Mon May 11 02:33:37 2020
> New Revision: 360887
> URL: https://svnweb.freebsd.org/chang
On Mon, Dec 16, 2019 at 5:44 PM Steven Hartland <
steven.hartl...@multiplay.co.uk> wrote:
> Sticky keyboard there Warner?
LOL
> On a more serious note the fact that the controllers lie about the
> underlying
> location of data, the impact of skipping the TRIM requests can have a
> much more
>
Yes, some systems with two disks in a mirror and an ssd as slog.
What are you trying to guard against? I have never seen an issue but would
like to be aware of potential problems with that system.
On Sun, Nov 3, 2019 at 2:32 PM Toomas Soome wrote:
>
>
> > On 3. Nov 2019, at
I believe this is/was a common configuration, at least the few
spinning disk based systems I have left have a slog.
On Sun, Nov 3, 2019 at 10:55 AM Andriy Gapon wrote:
>
> On 03/11/2019 15:25, Toomas Soome wrote:
> > Author: tsoome
> > Date: Sun Nov 3 13:25:47 2019
> > New Revision: 354283
> > U
The vast majority of contributors don't enjoy nit-picking on these
trivialities. If the broader developer community is not rallying for
the revert and some core conspiracy doesn't care about it either, that
forms the de facto opinion of the FreeBSD community of today that this
is trivial and irrele
I know of several people that have blocked your mail. Maybe a moment
for reflection on your attitude and approach if you want to be taken
seriously.
On Fri, May 31, 2019 at 8:50 AM Alexey Dokuchaev wrote:
>
> On Fri, May 31, 2019 at 03:20:50PM +, Brooks Davis wrote:
> > On Fri, May 24, 2019
Out of curiosity are you using this driver? Any performance data?
On Thu, Jan 17, 2019 at 4:21 PM Conrad Meyer wrote:
> Author: cem
> Date: Thu Jan 17 23:21:02 2019
> New Revision: 343125
> URL: https://svnweb.freebsd.org/changeset/base/343125
>
> Log:
> ioat(4): Set __result_use_check on ioat
But why, you can trivially see the open() call with truss or more advanced
tracers if you are debugging this
On Thu, Dec 13, 2018 at 6:39 PM Kubilay Kocak wrote:
> On 14/12/2018 12:06 pm, Jung-uk Kim wrote:
> > Author: jkim
> > Date: Fri Dec 14 01:06:34 2018
> > New Revision: 342057
> > URL: htt
>
>> On Mon, 2018-12-10 at 14:15 -0800, John Baldwin wrote:
>> > On 12/8/18 7:43 PM, Warner Losh wrote:
>> > >
>> > >
>> > >
>> > > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling > > > m <mailto:kevin.bowl...@kev009.com>
> > On 12/8/18 7:43 PM, Warner Losh wrote:
> > >
> > >
> > >
> > > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling > > m <mailto:kevin.bowl...@kev009.com> wrote:
> > >
> > > On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik >
On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik wrote:
>
> Fully satisfying solution would be that all architectures get 64-bit
> ops, even if in the worst case they end up taking a lock. Then
> subsystems would not have to ifdef on anything. However, there
> was some opposition to this proposal an
Author: kbowling (ports committer)
Date: Mon Nov 19 00:54:31 2018
New Revision: 340591
URL: https://svnweb.freebsd.org/changeset/base/340591
Log:
Retire sbsndptr() KPI
As of r340465 all consumers use sbsndptr_adv and sbsndptr_noadv
Reviewed by: gallatin
Approved by: krion (mentor)
Author: kbowling (ports committer)
Date: Tue Nov 13 09:19:07 2018
New Revision: 340393
URL: https://svnweb.freebsd.org/changeset/base/340393
Log:
powerpc64: reduce GENERIC64 diff versus amd64 GENERIC
Reviewed by: jhibbits
Approved by: timur (mentor)
Differential Revision:https
ppc64 will be the next arch after amd64 to get modern graphics
(https://github.com/POWER9BSD/freebsd/commits/projects/lkpi) but we
like the tier-2 status for now and will replay changes from amd64
GENERIC once I'm able to test.
FWIW evdev is the standard with libinput for X11 under Linux. It's
us
Without looking at the unbound source, I assume they want the
semantics of what we call SO_REUSEPORT_LB in FreeBSD >= 12.0. See
setsockopt(2) for a brief description.
Whether it makes sense to conditionalize that or simply disable the
sockopt I have no opinion on just sharing the above knowledge.
Author: kbowling (ports committer)
Date: Tue Oct 2 21:36:00 2018
New Revision: 339098
URL: https://svnweb.freebsd.org/changeset/base/339098
Log:
Use nda(4) on powerpc64
Approved by: re@ (kib), krion (mentor), imp
Differential Revision:https://reviews.freebsd.org/D17368
Modified
uot;]
jylefort [label="Jean-Yves Lefort\njylef...@freebsd.org\n2005/04/12"]
kami [label="Dominic Fandrey\nk...@freebsd.org\n2014/09/09"]
+kbowling [label="Kevin Bowling\nkbowl...@freebsd.org\n2018/09/02"]
kevlo [label="Kevin Lo\nke...@freebsd.org\n2003/02/21"
Legacy would be needed by existing these existing ppc64 at the moment
and I pointed out in the review that LP64 is not the correct heuristic
but was dismissed without understanding the point.
On Tue, Aug 28, 2018 at 10:36 AM, Mark Millard via svn-src-head
wrote:
> For the below I wonder if graphi
On Thu, Aug 23, 2018 at 10:55 AM, Rodney W. Grimes
wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> On Wed, Aug 22, 2018 at 10:08 AM Rodney W. Grimes <
>> free...@pdx.rh.cn85.dnsmgr.net> wrote:
>>
>> > I think this deprecation is a rather serious deviation
>> > from the stated policy, in t
Your fundamental premise is off base, drm is not gone, it's been moved.
Regards,
Kevin
On Wed, Aug 22, 2018 at 9:08 AM, Rodney W. Grimes
wrote:
>> >
>> > Could you please create a stable/11 deprecation change.
>> >
>>
>> What does that entail other than an update to UPDATING in stable/11?
>
> I
26 matches
Mail list logo
