From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15B03A934 for ; Wed, 23 Aug 2023 09:14:55 +0000 (UTC) Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-3fed963273cso27255615e9.1 for ; Wed, 23 Aug 2023 02:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaspace-dk.20221208.gappssmtp.com; s=20221208; t=1692782094; x=1693386894; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=qiZlM8QEOpDTpRFMe/2/zEZ6wsyKpsV1KUA2VGwkVqc=; b=TZmuqPNeD3vmbShzj7gSb9+WRe+VS3qWdT9gRNdlIP9KZZgdfonNFTcwLwx5mRJt4q ZN6MwyNgTnqxerFqVS838PDSa9SZahDI+0GrYqHbmOOI0lS1z9cmYY8xV/NJtu+8RZJo 6tQuut33WKBdRXsVpKVyM69X8LCHU2KjK3uJqfZjXbMlenzYj+FYyfvMDqZA33cydqgy XTmSgGZeHwVcHBM5nX+9NbJetLEwqVrJOHnKcl3ZIwQavAH4RDuNakYzvfwbxEhH8/ET ebPNY+1w72xFkKQFbxQILYIPWjBdxqGfbMHKXsQ+VYtIjpovbaEVa3H62hZEtJ8g71KQ g0PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692782094; x=1693386894; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qiZlM8QEOpDTpRFMe/2/zEZ6wsyKpsV1KUA2VGwkVqc=; b=R8VNKuq/QVVs7ZQCIrPvYWfAKraRRer0LMqcTlU2f5ZJPnRBeJ/cfLMDRRV6sLODuU iJkmT+SIyC7BW0dErh8cTAbr6xKW8E3bnKVYenaX5jtRl6VTOWXmDZ5Oo0Jy91ECT6MP s5WIrAPA9+suTtzPEvvlFqg0jTlOC2tQUBxWOuhcYda6GSJM+xC41AbpSn4PUN/qqrWx T9JV4V7w0sWBxJqdaWyetSVduuWi9qJlD0oxs4W9OHJhnkXlwiO+zzJEjJKNg02hr1tO zRCH22okJYOGm6MQOgzorLaZn7uoSj5ycEHoxddxRBSMfEDO0m5H2IkykdEHwpwb94dV plnw== X-Gm-Message-State: AOJu0Yydw5VObwARKyx16URNTGk0vNPNR008JKhBCMgizxekJAAypLqe Pu/K3PsT6W+xRWo7H70jck4dEg== X-Google-Smtp-Source: AGHT+IGmx49TcZyNIesZ0Y8hEQR3pLmQeKegxY8NL7lzkFIt1BTGvLiiowVfWMRULj4No2sYruY+WA== X-Received: by 2002:a05:600c:3007:b0:3fa:91d0:8ddb with SMTP id j7-20020a05600c300700b003fa91d08ddbmr9556489wmh.14.1692782093753; Wed, 23 Aug 2023 02:14:53 -0700 (PDT) Received: from localhost ([165.225.194.205]) by smtp.gmail.com with ESMTPSA id n22-20020a1c7216000000b003fefe70ec9csm2536983wmc.10.2023.08.23.02.14.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Aug 2023 02:14:53 -0700 (PDT) References: <20230711093303.1433770-1-aliceryhl@google.com> <20230711093303.1433770-7-aliceryhl@google.com> <87msyisvmi.fsf@metaspace.dk> User-agent: mu4e 1.10.5; emacs 28.2.50 From: "Andreas Hindborg (Samsung)" To: Benno Lossin Cc: Alice Ryhl , rust-for-linux@vger.kernel.org, Tejun Heo , Miguel Ojeda , Lai Jiangshan , Wedson Almeida Filho , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?Q?Bj=C3=B6rn?= Roy Baron , linux-kernel@vger.kernel.org, patches@lists.linux.dev Subject: Re: [PATCH v3 6/9] rust: workqueue: add helper for defining work_struct fields Date: Wed, 23 Aug 2023 11:06:37 +0200 In-reply-to: <87msyisvmi.fsf@metaspace.dk> Message-ID: <87il963ysz.fsf@metaspace.dk> Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain "Andreas Hindborg (Samsung)" writes: > Hi Benno, > > Benno Lossin writes: > > ... > >>> +/// Links for a work item. >>> +/// >>> +/// This struct contains a function pointer to the `run` function from the [`WorkItemPointer`] >>> +/// trait, and defines the linked list pointers necessary to enqueue a work item in a workqueue. >>> +/// >>> +/// Wraps the kernel's C `struct work_struct`. >>> +/// >>> +/// This is a helper type used to associate a `work_struct` with the [`WorkItem`] that uses it. >>> +#[repr(transparent)] >>> +pub struct Work { >>> + work: Opaque, >>> + _inner: PhantomData, >> >> Should this really be `PhantomData`? Are you dropping `T`s in the >> destructor of `Work`? I do not think so `PhantomData Box>` >> should do the trick. >> > > Could you elaborate what is the issue in having `PhantomData`? I played around with this and as far as I can tell, using `PhantomData Box>` does not disable dropck for T. Thus, `PhantomData` has the same effect as `PhantomData Box`, which is covariance over T and dropck: ```rust use std::marker::PhantomData; struct A { _marker: PhantomData Box>, } //#[cfg(disable)] impl Drop for A { fn drop(&mut self) { todo!() } } struct B {} fn main() { let (_a, b); b = B {}; _a = foo(&b); } fn foo<'a>(_b: &'a B) -> A<&'a B> { let a: A<&'a B> = A { _marker: PhantomData, }; a } ``` This is a little surprising to me since nomicon [1] explicitly marks `PhantomData` as "covariant (with drop check)" but only "covariant" for `PhantomData T>`. Not sure why you wanted the box? Best regards, Andreas [1] https://doc.rust-lang.org/nomicon/phantom-data.html#table-of-phantomdata-patterns